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

It illustrates some examples like:




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?

2 Answers 2

  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:


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

  • Thanks for the quick reply. So if i understand you correctly, irrespective of whatever client side code is sent via URL, the server won't parse it. But what happens if i utilize a php script that uses the query string parameters to do something. e.g. site.com/index.php?value=1 . Here, i can use xss as site.com/index.php?value=<script>alert('xss')</script>. Where my php script includes something like val = $_GET['value']
    – Karan
    May 11, 2013 at 18:27
  • 1
    @user85030: The server can parse it if you tell it to, effectively. As for the second bit... it only works if you echo the user-submitted value, or store it to re-echo it. PHP itself does not care about JS. It's the echo (render) that gives XSS all its power, not server processing. XSS is primarily aimed at redirecting users and/or stealing cookies. May 11, 2013 at 18:28
  • oh, okay. Got it. Just one more clarification. In the url where i have a javascript following a hashtag, when the browse receives a reply, does it first execute the javascripts on the page or does it first execute the javascript in the url?
    – Karan
    May 11, 2013 at 18:33
  • @user85030: the JS in the hashtag is never executed unless you inject it in an element. The rules are the same as the rest - if you do something like (jQuery) $("div").html(window.location.hash);, it's your problem to sanitize the hash and prevent script tags from getting in there. If you do not output the hash directly, you have nothing to fear. May 11, 2013 at 18:35
  • There is one thing to note, however. If you use $(location.hash), you are vulnerable. The reason being that $("string") where string is not a DOM selector will create the element... and thus run the script. This is, however, a feature and not a bug. May 11, 2013 at 18:38

Let's illustrate how a basic page request works:

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

So for example our index.php has the following:

    $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.

  • 1
    Appreciate your efforts in explaining a page request/reply mechanism.
    – Karan
    May 11, 2013 at 18:50
  • 1
    @HamZaDzCyberDeV: Bonus point for explaining what I brushed under the carpet. May 11, 2013 at 19:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .