Part four of the series detailing the OWASP top 10 web application vulnerabilities. (See intro)

On the surface of it, this might seem to have something to do with class type objects, but actually, it doesn't... So what are we talking about?

Well, the sort of objects we're talking about here are files, directories, database records or primary keys.

I find that using a specific example is the easiest way to explain these concepts, so consider the following URL:

The idea here, is that the parameter is used to specify the file to download. This could quite easily be exploited to return a unintended file by a hacker modifying the parameter.

What would happen if a hacker modified the URL to:


In the second JSP/Java/Tomcat example, they could get hold of the config file used to store user names and passwords - instant admin access!

This isn't limited to files - records identified by their primary keys are also vulnerable.

Once again, a hacker could easily modify the unique key in the following URL to return data that they might not be suppose to access:

So what do we do to avoid this situation?
Firstly, validate all input. If you're returning files, ensure that a hacker can't escape the input. This isn't always as easy as it sounds though - I recall some time ago in 2001 that IIS had a bug in it allowing directory traversals by using the overlong Unicode representations for / and . - %c0%af and %c1%9c. Using a combination of these basically bypassed all security checks and allowed executing commands on the server by inputting commands to the command shell. Basically, a hacker had complete access to the server. So be careful!

Probably most importantly, use a reference map to refer indirectly to objects, so that they're never shown publicly. If a hashtable of valid key/file names are stored server side and are referenced through the use of their keys from the browser, a hacker can't enter a file name/ record key that they're not supposed to have access to.

eg. instead of the first example above, a better approach would be:


Obviously, you only store those files in the hashtable that they're supposed to have access to, otherwise they would simply change the file id and once again access secure data.

So... Beware of your parameters and what they could be exposing.


Twitter Delicious Facebook Digg Stumbleupon Favorites More