Wednesday, September 19, 2007

A bit about security

I must admit that I don't know that much about the securing of websites. After asking around it seems that bad user input such as XSS (cross-side-scripting) are about 90% of the problem, so if you secure your website from malicious users trying to script you, you've done quite a bit about it.

I'm kind of new to XSS but now it is up to me to prevent it from happening on our site. So lets start with what XSS is. The thing is if you intend to have user input on your site and then present that input, then you are a target for scripting. (Which means that almoste every site out there are) Why? Say that you have a ordinary description field for a user. You would probably use a text area or something. Say that you just take the info from the user and then show it to him/her (I actually have a feeling that it's mostly a him), then it's totaly open for him to put every HTML-tag in the book in it, including the script-tag, and the site will render it next time it is show along with all the other HTML.

If I, for example, go <script>alert('This site sucks');</script> a ugly popup will show next time I reload the site. This could be used, and has been, for porn ads and other disturbing things you don't want on your site. But it could actually be put to use to more harmful things which I nor gonna show och know much about.

So what do you do about it? The answer is to escape it, which means that you translate all the tags into something that won't be interpretated as HTML and therefore just will be shown as text. The former example will then just show '<script>alert('This site sucks');</script>' as your presentation, which isn't that harmful.

You also have to be aware of SQL injections. which is when a user, via input, extends your queries to your database. This way they can get loads of info you don't wont to supply to a random user, such as passwords and creditcard numbers.

These problems is, as I said, very common and therefore most webframeworks have build in HTMLescaping and SQLinject prevention. So just use it. The motto is: 'Never trust user input'. Even if a users shouldn't be able to insert things in your queries or fields via your site they could do many bad things with scripts or commandline utilities such as curl.

I highly recommend that you watch this rails cast (and this and this) on this subject. And by the way, the functiion that escapes HTML for you in rails is h(). Just go : h(<script>alert('This site sucks');</script>) and your problem is solved, just don't forget to put it everywhere where malicious input/output can occur.

No comments: