Jun 27, 2012
Table of contents:
Cross-site scripting (XSS) is a type of website and web application vulnerability that allows an attacker to inject client-side code into a web page to breach security or to get access to unauthorised features. This will typically involve getting access to restricted content by stealing session or cookie data from another user.
The name XSS originates from the initial idea of loading malicious content within a website or web application, and usually involves JavaScript as the programming language of choice. However, these days XSS has come to represent all sorts of client-side injection techniques written in a number of different languages.
There have been a number of high-profile cases of XSS attacks on large established websites such as Twitter and MySpace, which just goes to show, even the big boys aren’t immune.
If you are developing professional websites or web applications you need to fully understand how these kind of exploits work and how you can prevent them. Web development security is a huge area that is often over-looked by even the better developers, but it can have very serious consequences if you are attacked. Here is everything you need to know to understand how XSS attacks work, and how you can prevent them in your websites.
There are basically two types of XSS attack, Non-persistent and Persistent.
A non-persistent exploit is where you have to actually provoke the script to run.
For example, if you are on a website with an unsecure search box, you might enter the following as a search query:
<script>alert("Naughty XSS");</script>;
The website would run this query then typically output it back on to the page. This would cause your little JavaScript alert box to run and therefore allow you to run any type of JavaScript on the page.
Now obviously, getting pop up boxes to open on a web page isn’t very useful. The attack comes when you trick someone to clicking on a link with the JavaScript exploit embedded. This can be done in a number of ways which I won’t get into. The victim would then open the page and cause the JavaScript to run. This is typically used to catch the cookie of a logged in user and send it to a file on the attackers server, although there are many other possibilities that can come from this sort of attack.
A persistent attack is when the script is actually saved to the server and so it is run whenever it is outputted to the browser. A fantastic example of a persistent XSS attack is what happened to MySpace a couple of years ago. For a full overview of exactly what happened click here, and for the technical break down click here.
A persistent XSS attack typically occurs on Social Networking type sites that allow user to save content into the system. The attacker will save the script into their profile page so whenever someone views that page the script is run in their browser. This can then manifest itself into the victims profile page and therefore spread itself throughout the social network.
In the case of the MySpace attack, the attacker managed to get over a million people to request his friendship within just a couple of days by forcing them to add him as friend if they looked at a person’s profile page that had been effected.
I’m not going to go into every detail of every single way you should be keeping your site secure because this post will be huge and you won’t really learn anything if I just give you a chunk of code to plugin to your website. It’s important to understand how these exploits work so you can be sure to test for them and ensure that your websites and web applications are safe.
The following are a two ways you should be ensuring your website or web application is safe. To be honest, a lot of this stuff is web dev security 101 and you should be doing it anyway, there is no excuse for writing crappy or insecure code.
The first thing you should be doing is making sure you encode and escape every possible way an attacker can enter data into your website or web app. This includes, forms, login boxes, content boxes and URLs. Basically whenever you accept data from your users you should treat it as potentially dangerous. You should sanitise any data you accept before doing anything with it, and especially before you save it to the database. There are various methods for doing this in each language, so I’m not going to start teaching you specific techniques, just makes sure you do it!
Secondly, whenever you output data to the browser, make sure you escape it. This includes data from the database, data from search boxes or errors in forms. Basically, you need to think of the context of how the data will appear in your website or web app and then escape it accordingly.
Dealing with Sessions and Cookies is a topic in its own right and so I’ll write-up a following post about how I deal with authentication security in the future. But basically, you need to ensure that you make it as hard as possible for an attacker to hijack another user’s session. This can be achieved in a number of ways with a forced check that does not solely rely on the cookie data. For example, if the session suddenly starts using a different IP or browser or other kinds of weird activity you could prompt the user to re-enter their password. Of course this is not bullet proof, and your method will be dependent on your use case, it’s just another way of making life difficult for an attacker.
XSS attacks pose a real threat and should be something that all web developers have knowledge of. Big name attacks on the likes of MySpace and Twitter show how even large established sites can fall victim. XSS attacks are extremely important because they can potentially expose your users to attacks. This is extremely important if you are handling sensitive data about them or you are dealing with eCommerce.
To prevent XSS attacks, all you really need to do is to ensure you are writing excellent quality reliable code. Treat all inputs as a potential exploit and try to learn as much as you can about website security so you can think like a hacker.
What ways do you find useful for preventing XSS attacks in your websites or web applications?