Security in Websites
Yesterday I talked a little bit about SOME of the stuff I do at Mediaworks; I’d like to continue that with some of the things that I’ve learned there.
One thing that I have becoming increasingly aware of is security in websites (or lack thereof). It’s kind of funny — whenever I visit a new website, one of my first thoughts is how I could break it, how I could ‘hijack’ the page. One might think that these are malicious things, used to hurt users of the site, but on the contrary, understanding exploits is key to protecting your own applications against outside attacks.
What actually sparked my interest in the security of websites was a nice Wikipedia article on XSS attacks. I had, of course, heard of XSS attacks before, but I didn’t really know what they were until I read the article. Immediately after reading Wikipedia, I did a little more research and found out a little bit about how such attacks are performed, and what can be accomplished. I took some of the ideas and techniques I read about, and applied them to the site I was currently working on at work. Sure enough, I was able to inject Javascript that was executed when the page was viewed. As a general rule, if, at any point on your site, a user could cause an alert box to appear through Javascript, your webpage is probably at risk.
One of the most common problems I’ve seen is with search fields. Enter a search of random characters, and see what happens. All too often, a website will say something like “Search query ‘fkljsdhkfj’ cannot be found”. My first thought when I see that is “Alright, let’s see what happens if I enter Javascript in that search field.” Surprisingly often, the Javascript will execute. Why is this a problem? Let’s say I send someone a link to the site (possibly a trusted site like eBay or Amazon), directly to the search query I specify (e.g., http://www.example.com?search=eviljavascript). The Javascript can execute, and do all kinds of things (taking cookie authentication information for instance, or my personal favorite, ‘hijacking the DOM’).
The attack described above is a pretty tame one. The user still has to click a URL to have the source execute. More malicious attacks enter script into a field that is saved to a database and displayed to other users at another time. In this fashion, potentially thousands of users can have the attackers script executed on their machines. A general example of this would be some sort of XSS vulnerability in a popular bulletin board program. If you were able to inject javascript into a popular post, hundreds or thousands of users that view the post would be effected.
The bottom line is that you have to assume the user is an attacker, and plan accordingly. All data should be sanitized. Nothing should ever be displayed to the user, even if only the user who entered it will see it, without being protected. Use functions to strip HTML or at the very least, Javascript from user input. Validate all user input — if you expect a 10 digit number, verify that that’s what you got. Do not rely on ’security’ like setting a max-size on form text fields. These sorts of protections are enforced client side, and can be removed.
Learning how would-be attackers think, and what they actually do, is one way to protect against these types of attacks. In a few days, I’ll talk a little bit about how I discovered a clever exploit in a service provided by a major web company.
September 15th, 2006 at 9:40 am
I had read some stuff about XSS when someone managed to send out a Phishing email a while ago that actually directed a user to the real www.paypal.com website, but when run would send the password to the phisher - they had altered the DOM. At the time I read the Wikipedia article, thought I understood it and left it at that - but reading your explanation made me realise that I had gotten the wrong impression of how it works. I’m going to go and try some of those attacks on my own site now, thanks.