I've recently come across the OWASP (The Open Web Application Security Project) and it's really opened up my eyes. http://www.owasp.org/index.php/Main_Page

According to their website:
"Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license."

The thing that interests me is that they've compiled a list of top 10 security risks focusing on web applications. Most developers have heard of some of the vulnerabilities that are listed, but few really understand them and fewer "code to the doc". The document details, implications and ways of avoiding the pitfalls. I believe that all developers should be well versed with this document or at least these concepts. This way, the chances of an application and/or data being compromised will be largely negated. Security is never a yes/no question, but I this is an excellent starting point.

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.

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...

Twitter Delicious Facebook Digg Stumbleupon Favorites More