Preventing Path Traversal Vulnerabilities
By far the most effective means of eliminating path traversal vulnerabilities is to avoid passing user-submitted data to any file system API. In many cases, including the original example GetImage.aspx?file=diagram1.jpg , it is entirely unnecessary for an application to do this. For most files that are not subject to any access control, the files can simply be placed within the web root and accessed via a direct URL. If this is not possible, the application can maintain a hard-coded list of image files that may be served by the page, and use a different identifier to specify which file is required, such as an index number. Any request containing an invalid identifier can be rejected, and there is no attack surface for users to manipulate the path of files delivered by the page.
In some cases, as with the workflow functionality that allows file uploading and downloading, it may be desirable to allow users to specify files by name, and developers may decide that the easiest way to implement this is by passing the user-supplied filename to file system APIs. In this situation, the application should take a defense-in-depth approach to place several obstacles in the way of a path traversal attack.
Here are some examples of defenses that may be used; ideally, as many of these as possible should be implemented together:
■ After performing all relevant decoding and canonicalization of the user-submitted filename, the application should check whether this contains either of the path traversal sequences (using backward or forward slashes) or any null bytes. If so, the application should stop processing the request. It should not attempt to perform any sanitization on the malicious filename.
■ The application should use a hard-coded list of permissible file types and reject any request for a different type (after the preceding decoding and canonicalization has been performed).
■ After performing all of its filtering on the user-supplied filename, the application should use suitable file system APIs to verify that nothing is amiss, and that the file to be accessed using that filename is located within the start directory specified by the application.
In Java, this can be achieved by instantiating a java.io.File object using the user-supplied filename and then calling the getCanonicalPath method on this object. If the string returned by this method does not begin with the name of the start directory, then the user has somehow bypassed the application’s input filters, and the request should be rejected.
In ASP.NET, this can be achieved by passing the user-supplied filename to the System.Io.Path.GetFullPath method and checking the returned string in the same way as described for Java.
■The application can mitigate the impact of most exploitable path traversal vulnerabilities by using a chrooted environment to access the directory containing the files to be accessed. In this situation, the chrooted directory is treated as if it is the file system root, and any redundant traversal sequences that attempt to step up above it are ignored. Chrooted file systems are supported natively on most Unix-based plat-forms. A similar effect can be achieved on Windows platforms (in relation to traversal vulnerabilities, at least) by mounting the relevant start directory as a new logical drive and using the associated drive letter to access its contents.
■ The application should integrate its defenses against path traversal attacks with its logging and alerting mechanisms. Whenever a request is received that contains path traversal sequences, this indicates likely malicious intent on the part of the user, and the application should log the request as an attempted security breach, terminate the user’s session, and if applicable, suspend the user’s account and generate an alert to an administrator.
NEXT is..Attacking Application Logic……………..,,,,,,,,,,,,,,,,,,,,,,,,
