Latest Improvements in the Detection of DOM XSS Vulnerabilities

The latest build of Acunetix Web Vulnerability Scanner (Build 20131023) released yesterday, contains important improvements in the detection of DOM XSS vulnerabilities. Our DeepScan technology was also further strengthened in this build.

Take the following piece of code for example:

dom-xss-vulnerable-source-code

DOM XSS vulnerable source code

This code is vulnerable to a DOM XSS vulnerability. Why? Let’s analyze this code line by line:

1. var defaultLanguage = document.location.href.substring(document.location.href.indexOf(“default=”)+8);

This line of code does two things. It searches the document URL for the string default= and then it extract the text that comes after using the substring function.

Let’s say that we have the URL http://tests/domXSS/vuln.php?default=russian. In this case the defaultLanguage variable will contain the string russian.

2. defaultLanguage = decodeURIComponent(defaultLanguage);

The value of the defaultLanguage variable is decoded here because nowadays most browsers are automatically URL encoding parts of the URL.

3. document.write(“<OPTION value=1>” + defaultLanguage + “</OPTION>”);

And in the end, the contents of the defaultLanguage variable are written into the DOM tree.

Because the variable content is written into the DOM tree without any encoding/filtering this is creating a DOM XSS vulnerability. An attacker could prepare an URL like http://tests/domXSS/vuln.php?default=</option><script>alert(1)</script> and execute javascript code in the context of the victim.

It’s not easy to detect such a vulnerability in an automated way.

  • The scanner must be capable to execute Javascript code.
  • The scanner must be capable of tracing the execution of Javascript code and detect if user input from various sources (like the location/documentURI/URL) reaches dangerous sinks where the code is executed (document.write/innerHTML/the eval function …)
  • That’s not enough in this case. Here, the script is searching the location URL for a specific magic string (default=) and extracts everything that comes after. If the scanner doesn’t provide a URL that contains this magic string, the vulnerability will not be found.

The latest version of Acunetix WVS can do all these things. It will figure out that the script is looking for a specific magic string in the URL and provide an URL that contains this magic string.

When you scan this code with the latest version the following alert will be reported:

acunetix-wvs-dom-xss-vulnerability-alert

DOM XSS vulnerability alert

As you can see the alert contains some useful information. It mentions that the source of this DOM XSS is the location parameter. Also, the execution sink is document.write. There is also a stack trace and from this stack trace we can find out that the vulnerability occurs in the line number 8.

Line number 8 is

document.write(“<OPTION value=1>” + defaultLanguage + “</OPTION>”);

In this line the user input is written in the DOM tree causing the DOM XSS vulnerability.

In the end, here is a screenshot of this vulnerability exploited on Firefox.

firefox-dom-xss

Exploit DOM XSS vulnerability on Firefox

Share this post
  • Hi sir, does WVS check for all browsers whether it vulnerable or not?

    • Hi,

      The vulnerability would exist in the website, not in the browser. Various browsers use different techniques to prevent XSS from occurring, however the website would still be vulnerable.

  • Leave a Reply

    Your email address will not be published.


    *