19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

380 Chapter 10 n Attacking Back-End Components<br />

is not possible, <strong>the</strong> <strong>application</strong> can maintain a hard-coded list of image files that<br />

may be served by <strong>the</strong> page. It can use a different identifier to specify which<br />

file is required, such as an index number. Any request containing an invalid<br />

identifier can be rejected, and <strong>the</strong>re is no attack surface for users to manipulate<br />

<strong>the</strong> path of files delivered by <strong>the</strong> page.<br />

In some cases, as with <strong>the</strong> work flow functionality that allows file uploading<br />

and downloading, it may be desirable to allow users to specify files by name.<br />

Developers may decide that <strong>the</strong> easiest way to implement this is by passing<br />

<strong>the</strong> user-supplied filename to filesystem APIs. In this situation, <strong>the</strong> <strong>application</strong><br />

should take a defense-in-depth approach to place several obstacles in <strong>the</strong> way<br />

of a path traversal attack.<br />

Here are some examples of defenses that may be used; ideally, as many of<br />

<strong>the</strong>se as possible should be implemented toge<strong>the</strong>r:<br />

n After performing all relevant decoding and canonicalization of <strong>the</strong> usersubmitted<br />

filename, <strong>the</strong> <strong>application</strong> should check whe<strong>the</strong>r it contains ei<strong>the</strong>r<br />

of <strong>the</strong> path traversal sequences (using backslashes or forward slashes) or<br />

any null bytes. If so, <strong>the</strong> <strong>application</strong> should stop processing <strong>the</strong> request. It<br />

should not attempt to perform any sanitization on <strong>the</strong> malicious filename.<br />

n The <strong>application</strong> should use a hard-coded list of permissible file types and<br />

reject any request for a different type (after <strong>the</strong> preceding decoding and<br />

canonicalization have been performed).<br />

n After performing all its filtering on <strong>the</strong> user-supplied filename, <strong>the</strong> <strong>application</strong><br />

should use suitable filesystem APIs to verify that nothing is amiss<br />

and that <strong>the</strong> file to be accessed using that filename is located in <strong>the</strong> start<br />

directory specified by <strong>the</strong> <strong>application</strong>.<br />

In Java, this can be achieved by instantiating a java.io.File object using<br />

<strong>the</strong> user-supplied filename and <strong>the</strong>n calling <strong>the</strong> getCanonicalPath method<br />

on this object. If <strong>the</strong> string returned by this method does not begin with <strong>the</strong><br />

name of <strong>the</strong> start directory, <strong>the</strong> user has somehow bypassed <strong>the</strong> <strong>application</strong>’s<br />

input filters, and <strong>the</strong> request should be rejected.<br />

In ASP.NET, this can be achieved by passing <strong>the</strong> user-supplied filename<br />

to <strong>the</strong> System.Io.Path.GetFullPath method and checking <strong>the</strong> returned<br />

string in <strong>the</strong> same way as described for Java.<br />

The <strong>application</strong> can mitigate <strong>the</strong> impact of most exploitable path traversal<br />

vulnerabilities by using a chrooted environment to access <strong>the</strong> directory containing<br />

<strong>the</strong> files to be accessed. In this situation, <strong>the</strong> chrooted directory is treated as

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!