DOM Based XSS

DOM 

When  a web page is loaded, browser creates a Document Object Model. It is a platform and language-neutral interface that allows scripts to dynamically access and update the content, structure, and style of a document.

DOM-Based XSS : It is a Cross-Site-Scripting attack wherein the attack payload is executed as a result of modifying DOM environment in the victim’s browser used by itself.

The important thing to consider here that the HTTP response does not change but the client side code in the page behaves differently because of the malicious code injected by the attacker.

Note: DOM XSS can be executed in Chrome, therefore if you would like to repeat the steps mentioned below, it is recommended to use chrome browser. Firefox has an inbuilt protection against DOM-Based XSS therefore DOM attacks might not work in Firefox.

---

Few Findings in Wild

Target : Outbrain.com

Global Rank : 81

Rank in US: 55

If you open www.outbrain.com and go to their privacy policy, you might notice they have several links  under the Quick guide to contents.

 

If you copy the link location of any of those links, the URL might look like as follows:

http://www.outbrain.com/legal/privacy#information_we_collect_automatically which involves an anchor tag that gives us a potential to test if it is vulnerable to DOM Based XSS by just sending a malicious Javascript after the anchor tag as follows:

  and the result will be as follows:

  

---

Now the question arise, why it has happened?

If you check the source code at the client side, you might notice that it is using a java script called http://www.outbrain.com/assets/javascripts/site.min.js?v=818dda9e6d42582ad7c0d8b80332b1b1

Open it into a new tab and search for "document.location.hash", you will find following code which is actually the root cause in this case which leads to DOM based XSS

if(document.location.hash){var a=$('[anchor="'+document.location.hash.substring(1)+'"]'

---

Another example

Target : http://recode.net/

One of the leading tech news site

If you open the URL, you will notice the “Follow” section at the bottom of the page and there if you move your cursor over to “RSS”, you might notice that it is using an anchor tag that will give us a potential to execute or test DOM XSS. The URL would look like as following:

http://recode.net/follow-us/#rss Now in order to execute a DOM based XSS just insert your malicious code after the anchor tag as follow:

   and the result will be as following:

 

---

Root Cause :

Chrome provides a very useful feature where we can debug an application from the client side which might help us to identify the root cause of the DOM or even identifying a DOM based XSS. Open Chorome Console and open following URL

, now the chrome console will automatically give you this warning:

For further details, click onto the link mentioned in Chrome Console, it will further redirect you to the exact malicious code which is responsible for DOM XSS. If you really want to make sure whether this is the only code which is malicious or causing a DOM XSS then you can use the debug option available in Chrome. Set a breakpoint where you feel the vulnerable code lies, and check the value of any parameter by using the command console.log(); , Here we are trying to check the value of "h", whether it is the real culprit for this XSS or not.

One you refresh the page using the same URL, you will notice in the console log that the value of h contains your malicious code which is trigerring the DOM XSS. You will notice that the parameter ‘h’ contains the value of your malicious code.

In this case , they are using old jquery packge which is vulnerable to DOM based XSS:

/*! jQuery v2.0.3 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license

//@ sourceMappingURL=jquery-2.0.3.min.map

---

Another example:

Target: http://huffingtonpost.com/

Global Rank: 135

Rank in USA: 37

An important phenomena that has happened here, if you look at the screen shot, you might notice in the URL that the site has removed all the malicious characters from the URL
www.huffingtonpost.de/big-news/#imgsrc=xonerror=prompt1

But the XSS payload has been already executed before the application replaces the malicious characters. It would have been better to check the malicious characters before the payload executes but here developers have made a little mistake.

---

There are tons of applications that are vulnerable to DOM-Based XSS and it's quite an easy task for attackers to find out if an application is vulnerable to DOM based XSS and of course it's not very difficult to exploit the found vulnerability.

The root cause of DOM based XSS is the JavaScripts APIs that are vulnerable to DOM based XSS. Since deveopers uses the third party APIs very frequently because of various functionalities. But very often they forget to check whether it has some security loopholes or not because they just only focus on the functionalities. It is highly recommended to the developers whenever they try to use  a third party APIs, they should test and verify first whether it has some kind of bug or not. Moreovere keep an eye on available patches.