XSS: Parsing Javascript

Question

Reading about DOM based XSS from http://www.webappsec.org/projects/articles/071105.shtml

It illustrates some examples like:

http://www.vulnerable.site/welcome.html?foobar=name=<script>alert(document.cookie)<script>&name=Joe

and

 http://www.vulnerable.site/attachment.cgi?id=&action=foobar#<script>alert(document.cookie)</script>

1) In what sequence does a server and a browser parse javascript? Let's say for example 1), as soon as the above request is typed in a browser and sent to vulnerable.site, the cgi would handle the request via GET/POST parameters. Here, it would extract the required values from the GET/POST request, do some server side processing and return back a response in html. So where is the javascript in one of the parameters embedded in the response?

2) Similarly, for example 2) i read that # character would prevent the to be sent to the server side. So the server will only receive a request like http://www.vulnerable.site/attachment.cgi?id=&action=foobar and not the complete url. So what happens to the javascript that follows? Does the browser run it directly?

Answer 1

1. The server does not parse JavaScript except under very specific circumstances (i.e. you run NodeJS and you eval() a user input. Someone would have to be bloody stupid to do that or have a very valid reason to do so). So, the server does not see/care about the actual content of the code, and it won't be executed server-side. The reason for something like this is that, usually, user values are usually echoed somewhere on the page - this is why you pass them through an URL or store them on the server - so that they are used. When the server has sent its reply, the browser then runs whatever code it gets.

2. Indeed, you are correct on this. The hashtag is never sent to the server; however, there may be some client-side processing, most notably with MVC libraries like Spine.js. These things use the hashtag value to store history elements and perform actions based on them - like showing pages, doing stuff or echoing code.

You'll notice that in both cases, the vector is "echoing code". The entire purpose is to get an extra script tag on your page, where it will run and alert cookies. The first one, once corrected, is a very good example of another flaw:

http://www.vulnerable.site/welcome.html?foobar=&name=<script>alert(document.cookie)</script>&name=Joe

This request has two name parameters. HTTP pollution? Likely.

Answer 2

Let's illustrate how a basic page request works:

                            Request
                           index.php
#4 Processing |--------| 1#-----------> |--------|   #2 Processing
HTML/CSS/JS   | Client |                | Server |    the requet
 etc...       |--------| <-----------#3 |--------|    
                           Sending
                         the processed
                             page

So for example our index.php has the following:

<?php
    $name = $_GET['name'];
    echo 'Your name is' . $name;
?>

For a normal user this will work as expected, he will fill in a form his name and no problem. An hacker would fill a malicious javascript. For example: index.php?name=<script>alert('hello hacker');</script>.

1. Asking for index.php?name=<script>alert('hello hacker');</script>.
2. PHP get's the name parameter which is <script>alert('hello hacker');</script> in this case.
3. PHP will send the page with Your name is <script>alert('hello hacker');</script> in it.
4. The client browser will read and execute the JS tag, this would result into an alert box "hello hacker".

So you may think why and how is this bad ? Well the script can be "obfuscated" (to make it unreadable) and sent to a victim, when the victim clicks on it the script may be used for stealing cookies, injecting malware or even hacking the system with a 0-day exploit.