On the Internet, security is overrated. Every third site you visit talks about it. But still, not many sites take steps to implement it. This has been the complaint of people all these years and is still true today. Unless it is a site that is dealing with financial transactions, most interfaces provided by these sites are non-secure and prone to client side attacks. I believe it is a false assumption that unless your site is processing a credit card payments, it doesn’t need security. Security is not just about protecting ‘monetary transactions’. It is more than that, it involves protecting your computational resources (bandwidth, CPU usage), intellectual resources (JS files, web services) and of course, the services that the site is providing (like acting as a SMS gateway).

In this post I take a look at some ridiculously simple security blunders committed by popular sites. These might not always be critical but provide an interesting insight into the design quality metrics followed at these companies.

While surfing the Net, whenever I see a website offering a cool service, my natural instinct is to find out how they are doing it. For example, Rediff used to have this ActiveX based multilingual mail composition feature, which they replaced with a JavaScript based one. Cool! So now I could work on Firefox and still send my mail in Hindi! How (naively?) were they doing this? Create an IFrame and put the entire composition feature in it. Hmmm, OK, but couldn’t someone just rip off the JS files and create, say, a multilingual composition plugin for WordPress using their code. Access to the .js files doesn’t even require a login to the Rediff servers and using them is as easy as pointing the URL to http://f1mail.rediff.com/quill/QuillPadWeb.html. I am not sure what their testing team (if they have one) thought of this, but this allows someone to use the cool text entry interface by just copying 4 files off the Rediff site.


The easiest way to thwart leechers is to deny access to the scripts unless you are logged on. That would take care of direct linking (protecting computational resources). But there’s no easy solution if someone just copies the files off the server and hosts them on his website (protecting intellectual resources). What do you do then? Probably obfuscate the code enough so that he never knows what file he has to copy. Yahoo mail does an excellent job of the obfuscation. Even their images are protected (in a loose way) by referring them through their MD5 hashes; enough to deter a casual hacker.

Another flaw is doing all (and I mean ALL) the validation at the client side using JavaScript. Client side validation is a nice way to reduce load at the server end. But sometimes, this solution is implemented without safeguards.

While designing any API, there is a golden rule that has to be followed… `</p>

All input is evil

` Agreed, you have JS to check and ensure that the user input is correct. But what if I inject code through your web service using a simple script debugger like Visual Studio for IE and Venkman for Firefox. Even if I am not able to inject code, I will certainly be able to inject syntactically valid input data which is still invalid. To illustrate, imagine a banking service where the amount that can be withdrawn is checked against current balance using JavaScript. I could very well skip the function, overwrite the function which gets the current balance and a lot more. Unless the server is checking the validity of the transaction itself, I would be able to make any kind of transaction. In my [next post](/blog/2007/06/inspecting-web-interfaces/) I will discuss, some techniques that can be misused to thwart JavaScript based validations. The purpose of the post will be to further educate software designers about the pitfalls of client side validation which is not backed by robust server side validation.