Testing for Local File Inclusion - Revision history

DhirajMishra: /* Local File Inclusion*/

2017-06-25T05:20:26Z

‎Local File Inclusion

Andrew Muller at 13:20, 8 August 2014

2014-08-08T13:20:55Z

Andrew Muller at 16:24, 31 July 2014

2014-07-31T16:24:38Z

Andrew Muller at 16:22, 31 July 2014

2014-07-31T16:22:24Z

Jane O'Connor: Final edit

2014-05-19T10:20:58Z

Final edit

Davide Danelon: Mitigation added and minor updates

2014-03-06T16:45:19Z

Mitigation added and minor updates

Alexander Antukh: Blackbox chapter is updated

2013-09-28T12:17:59Z

Blackbox chapter is updated

Alexander Antukh: Brief summary (wiki) added

2013-09-14T18:21:36Z

Brief summary (wiki) added

Alexander Antukh: Page created

2013-09-14T17:03:11Z

Page created

New page

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Here comes Brief Summary about File Inclusion vulnerability

== Description of the Issue ==

Why is it so bad

== Black Box testing and example ==

Black box

== Gray Box testing and example ==

Gray box

== References ==

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

<br>

@@ Line 58: / Line 58: @@
 <pre>
 http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
 </pre>

@@ Line 61: / Line 61: @@
-== Mitigation ==
+== References ==
-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.
+* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
-== References ==
+== Remediation ==
-* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
+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.

← Older revision		Revision as of 16:24, 31 July 2014
Line 11:		Line 11:
	*Denial of Service (DoS)		*Denial of Service (DoS)
	*Sensitive Information Disclosure		*Sensitive Information Disclosure
−
−
−	~~The File inclusion vulnerability could be of two types:~~
−	* Local
−	* Remote
−

@@ 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 18: / Line 18: @@
-Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, 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 directory traversal characters (such as dot-dot-slash) 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.
+'''Local File Inclusion''' (also known as LFI) is the process of including files, that are already locally present on the server, 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 directory traversal characters (such as dot-dot-slash) 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.
-== Black Box testing and example ==
+== How to Test ==
 Since LFI 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.

@@ Line 2: / Line 2: @@
 == 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 9: / Line 11: @@
 *Denial of Service (DoS)
 *Sensitive Information Disclosure
 The File inclusion vulnerability could be of two types:
@@ Line 22: / Line 25: @@
 == Black Box testing and example ==
-Since LFI 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 example:
+Since LFI 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.
 <pre>
 http://vulnerable_host/preview.php?file=example.html
 </pre>
 This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server.
 Typical proof-of-concept would be to load passwd file:
 <pre>
 http://vulnerable_host/preview.php?file=../../../../etc/passwd
 </pre>
 If the above mentioned conditions are met, an attacker would see something like the following:
@@ Line 42: / Line 53: @@
 ...
 </pre>
 Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code:
@@ Line 47: / Line 59: @@
 <?php “include/”.include($_GET['filename'].“.php”); ?>
 </pre>
 In the case, simple substitution with arbitrary filename would not work as the postfix 'php' is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes:
 <pre>
 http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
 </pre>
 == 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 ==
@@ Line 62: / Line 77: @@
 * Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
 * Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

@@ Line 12: / Line 12: @@
 == Description of the Issue ==
-−
-Why is it so bad
+Local File Inclusion (also known as LFI) is the process of including local files on a server through the web browser. This vulnerability occurs when a page include is not properly sanitized, and allows directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, one should keep in mind it is also common in other technologies such as JSP, ASP and others.
 == Black Box testing and example ==
-Black box
+Since LFI occurs when page includes are not properly sanitized, in a blackbox testing approach one should look for scripts which take filenames as parameters. Consider the following example:
 == Gray Box testing and example ==
 Gray box
 == References ==
-* Wikipedia - http://www.wikipedia.org
+* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
 <br>

@@ Line 3: / Line 3: @@
 == Brief Summary ==
-Here comes Brief Summary about File Inclusion vulnerability
+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:
 == Description of the Issue ==