Tech News

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:

http://myserver/index.jsp?getfile=myreport.doc
or
http://myserver/index.aspx?getfile=myreport.doc
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:

http://myserver/index.aspx?getfile=/../web.configor
http://myserver/index.jsp?getfile=../../../tomcat/conf/tomcat-users.xml

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:

http://myserver/viewAccountBalance.jsp?accountNr=1234
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:

http://myserver/index.jsp?getfileByID=2

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.

Microsoft has just announced that it will purchase Skype for $8.5bn.

On the surface of it it seems as though it's a great purchase with possible integration with Xbox, Windows Phone 7, Live.com etc. But has it come at too high a cost?

In 2009, 70% of Skype was sold for $2bn. 2 years later, it's bought for $8.5bn? I doubt that Skype's value has increased to the degree which justifies the price and the stock market seems to agree - Microsoft's share price is down slightly for the day by 0.62%, in spite of the NASDAQ gaining 1.01%.


If Microsoft can integrate it successfully with the rest of it's products, it may be able to create an even stronger suite which might also strengthen it's case against iOS from Mac and Linux. There may not be any direct profits, but may be worth it when considering total sales and products.


It's yet too be seen whether this will be the right decision...