Continuing the series on OWASP Top 10 testing techniques, this article addresses an often overlooked functionality...
which can pose a significant risk to Web application owners: insecure file references. The official OWASP title for this is “insecure direct object references” which is technically more accurate, albeit not as readily understood. In this article, I will explain the vulnerability and provide testing techniques to address it.
Insecure direct object references are direct references to objects stored within an application server. In this attack, the attacker changes a reference from one system-level object to another; for instance, the attacker changes a reference for /img/my_gif.gif to /../../windows/system32/ntuser.dat. By launching this attack, the attacker takes advantage of improper application and system configurations, and is able to retrieve files from the system that were not intended for public consumption. Because path traversal is in its own OWASP category, this article focuses on attacks exploiting poorly-designed file handlers.
The attack generally leverages two implementation or configuration errors. First, a Web application should be white listing all file requests -- at the very least, white listing requests to a given directory or file type. Secondly, a Web application should never grant access to files outside of the application itself. A good file handler should 1) white list acceptable file types to be served up by the handler (for instance, jpg or gif), 2) limit access to a specified folder or a list of approved folders, 3) deny access outside of the application itself, and 4) never serve up configuration or operating system level files. It is easier to develop and maintain “white listed” file handlers than “blacklisted” file handlers.
There are several techniques you should leverage in detecting and proving insecure file references. First, keep in mind that the HTML source of a Web application page is your best friend. You will learn a vast amount about an application by scanning the source. In this type of testing, you will need to scan the source for a “file handler” (this is an actual implementation concept in ASP.net, and an often-used concept in JSP applications). In .NET, this functionality was included to speed up the response time for Web servers delivering binary data (IIS was notoriously slow at this process). You’ll find your file handler sometimes by name (filehandler.aspx), other times by function (getFile(filehandler.aspx)). By searching source code, you’ll quickly detect file handlers and their single point of entry.
The key to testing a file handler is to test for each major equivalence class. That would include:
- files within the application which should not be publicly available (for instance, .CS source files)
- files outside of the application but within the security context of the running server (IIS, Tomcat, etc.) Often these are XML configuration files.
- files outside of the application and outside of the application’s security context such as Windows configuration files.
- files not of a standard Web type -- not .jpg, .gif, .html, etc. These are often executables (.exe) or others.
An example should illustrate how to test a file handler. Step by step, let’s walk through test cases:
- Review source: search the source code for “handler” or similar text. If the search text isn’t found, start searching for file types which go through a common central function – often .js files or .jpg/.gif files will be served up by a common handler.
- For each attack, intercept the server request and modify the string being sent to the file handler. For instance, modify ‘filehandler.aspx?file=”banner.gif”’ to ‘filehandler.asp?file=”standard.css”
- A filehandler designed to serve JPGs should be attacked to force a different file type, such as .js or even .exe. You need to be familiar with the target platform’s Web server and the directory structure to accomplish this; research your server type before attempting these attacks.
- Next, attempt to retrieve application configuration files such as the workers2.properties (located in server_root/conf directory of a Tomcat server).
- Next, attempt to combine a direct object reference with a directory traversal attack. Some applications are configured to run in high-privilege access (often done during design and implementation, to reduce administrative overhead), which enables the application to access operating system and “root” level objects. If you know the application is running on a Windows server, for example, play with directory traversal until you can attack the %windir%/System32 directory, and retrieve any file (arp.exe is a good example). For instance, to traverse from a Web application running in C:\inetpub\wwwroot\myapp, try “..\..\..\windows\system32\arp.exe”
Over time, you will profile your application and begin to understand what vulnerabilities were left in various file handlers. Take note: finding, probing and profiling file handlers can be a tedious process. There are often numerous filehandlers in a given Web application, and some handlers may actually be partially secured. One alternative strategy is to perform a code review or an interview with an application developer -- once discovered, the source code can be examined to ensure the appropriate white listing has been implemented.
Numerous Web application scanning tools and source code analysis tools are available which can detect file handlers. In cases such as this, the time saved by running a tool can easily justify the investment cost for that tool. If you are testing Web applications on a regular basis, seriously consider the investment.
For more information about direct file object access, see the OWASP page for the topic: https://www.owasp.org/index.php/Top_10_2010-A4