This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)"

From OWASP
Jump to: navigation, search
m (spellcheck)
m (Spell check)
Line 12: Line 12:
 
==Description of the Issue==
 
==Description of the Issue==
  
Determining how web servers handle requests corresponding to files having different extensions may help to understand web server behavior depending on the kind of files we try to access. For example, it can help understand which file extensions are returned as text/plain versus those which cause execution on the server side. The latter are indicative of technologies / languages / plugins which are used by web servers or application servers, and may provide additional insight on how the web application is engineered. For example, a “.pl” extension is usually associated with server-side Perl support (though the file extension alone may be deceptive and not fully conclusive; for example, Perl server-side resources might be renamed to conceal the fact that they are indeed Perl related). See also next section on “web server components” for more on identifying server side technologies and components.
+
Determining how web servers handle requests corresponding to files having different extensions may help to understand web server behaviour depending on the kind of files we try to access. For example, it can help understand which file extensions are returned as text/plain versus those which cause execution on the server side. The latter are indicative of technologies / languages / plugins which are used by web servers or application servers, and may provide additional insight on how the web application is engineered. For example, a “.pl” extension is usually associated with server-side Perl support (though the file extension alone may be deceptive and not fully conclusive; for example, Perl server-side resources might be renamed to conceal the fact that they are indeed Perl related). See also next section on “web server components” for more on identifying server side technologies and components.
  
  
Line 18: Line 18:
  
 
Submit http[s] requests involving different file extensions and verify how they are handled. These verifications should be on a per web directory basis. Verify directories which allow script execution. Web server directories can be identified by vulnerability scanners, which look for the presence of well-known directories. In addition, mirroring the web site structure allows to reconstruct the tree of web directories served by the application.
 
Submit http[s] requests involving different file extensions and verify how they are handled. These verifications should be on a per web directory basis. Verify directories which allow script execution. Web server directories can be identified by vulnerability scanners, which look for the presence of well-known directories. In addition, mirroring the web site structure allows to reconstruct the tree of web directories served by the application.
In case the web application architecture is load-balanced, it is important to assess all of the web servers. This may or may not be easy depending on the configuration of the balancing infrastructure. In a redounded infrastructure there may be slight variations in the configuration of individual web / application servers, this may happen for example if the web architecture employs heterogeneous technologies (think of a set of IIS and Apache web servers in a load-balancing configuration, which may introduce slight asymmetric behavior between themselves, and possibly different vulnerabilities).
+
In case the web application architecture is load-balanced, it is important to assess all of the web servers. This may or may not be easy depending on the configuration of the balancing infrastructure. In a redounded infrastructure there may be slight variations in the configuration of individual web / application servers, this may happen for example if the web architecture employs heterogeneous technologies (think of a set of IIS and Apache web servers in a load-balancing configuration, which may introduce slight asymmetric behaviour between themselves, and possibly different vulnerabilities).
 
'''Example:'''<br>
 
'''Example:'''<br>
 
We have identified the existence of a file named connection.inc. Trying to access it directly gives back its contents, which are:
 
We have identified the existence of a file named connection.inc. Trying to access it directly gives back its contents, which are:
Line 36: Line 36:
  
 
Performing white box testing against file extensions handling amounts at checking the configurations of web server(s) / application server(s) taking part in the web application architecture, and verifying how they are instructed to serve different file extensions.
 
Performing white box testing against file extensions handling amounts at checking the configurations of web server(s) / application server(s) taking part in the web application architecture, and verifying how they are instructed to serve different file extensions.
If the web application relies on a load-balanced, etherogeneous infrastructure, determine whether this may introduce different behavior.
+
If the web application relies on a load-balanced, heterogeneous infrastructure, determine whether this may introduce different behaviour.
  
  

Revision as of 20:07, 6 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

...To review and expand...

Brief Summary

File extensions are commonly used in web servers to easily determine which technologies / languages / plugins must be used to fulfill the web request.

While this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the pentester useful information about the underlying technologies used in a web appliance and greatly simplifies the task of determining the attack scenario to be used on peculiar technologies.

In addition to this misconfiguration in web servers could easily reveal confidential information about access credentials.

Description of the Issue

Determining how web servers handle requests corresponding to files having different extensions may help to understand web server behaviour depending on the kind of files we try to access. For example, it can help understand which file extensions are returned as text/plain versus those which cause execution on the server side. The latter are indicative of technologies / languages / plugins which are used by web servers or application servers, and may provide additional insight on how the web application is engineered. For example, a “.pl” extension is usually associated with server-side Perl support (though the file extension alone may be deceptive and not fully conclusive; for example, Perl server-side resources might be renamed to conceal the fact that they are indeed Perl related). See also next section on “web server components” for more on identifying server side technologies and components.


Black Box testing and example

Submit http[s] requests involving different file extensions and verify how they are handled. These verifications should be on a per web directory basis. Verify directories which allow script execution. Web server directories can be identified by vulnerability scanners, which look for the presence of well-known directories. In addition, mirroring the web site structure allows to reconstruct the tree of web directories served by the application. In case the web application architecture is load-balanced, it is important to assess all of the web servers. This may or may not be easy depending on the configuration of the balancing infrastructure. In a redounded infrastructure there may be slight variations in the configuration of individual web / application servers, this may happen for example if the web architecture employs heterogeneous technologies (think of a set of IIS and Apache web servers in a load-balancing configuration, which may introduce slight asymmetric behaviour between themselves, and possibly different vulnerabilities). Example:
We have identified the existence of a file named connection.inc. Trying to access it directly gives back its contents, which are:

<?
   	mysql_connect("127.0.0.1", "root", "")
        or die("Could not connect");
 
?>

We determine the existence of a MySQL DBMS back end, and the (weak) credentials used by the web application to access it. This example (which occurred in a real assessment) shows how dangerous can be the access to some kind of files. Whitepapers

Gray Box testing and example

Performing white box testing against file extensions handling amounts at checking the configurations of web server(s) / application server(s) taking part in the web application architecture, and verifying how they are instructed to serve different file extensions. If the web application relies on a load-balanced, heterogeneous infrastructure, determine whether this may introduce different behaviour.


References

Whitepapers
Tools

Vulnerability scanners, such as Nessus and Nikto check for the existence of well-known web directories. They may allow as well to download the web site structure, which is helpful when trying to determine the configuration of web directories and how individual file extensions are served. Other tools that can be used for this purpose include wget (http://www.gnu.org/software/wget/) and curl (http://curl.haxx.se), or google for “web mirroring tools”.



OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents