Advance XSS Attacks, DOM Based

 

Robert ‘rsnake’ Hensen is considered as Guru of XSS. Let’s learn advance DOM based attack from his own book “XSS attacks: cross-site scripting exploits and defense”
Preview of his book is available at http://books.google.com/books?id=Imt5Crr0jJcC

DOM-based is unique form of XSS, used very similarly to non-persistent, but where the JavaScript malware payload doesn’t need to be sent or echoed by the Web site to exploit auser. Consider our eCommerce Web site example (Figure 1.1.), where a feature on the Website is used to display sales promotions.The following URL queries the backend database for the information specified by the product_id value which is shown to the user. (Figure 1.2)

To make the user experience a bit more dynamicity, the title value of the URL’s can be updated on the fly to include different impulse-buy text

http://victim/promo?product_id=100&title=Last+Chance!http://victim/promo?product_id=100&title=Only+10+Left!

Etc.

The value of the title is automatically written to the page using some resident JavaScript.

This is where the problem is. In this scenario, the client-side JavaScript blindly trusts the data contained in the URL and renders it to the screen.This trust can be leveraged to craft the following URL that contains some JavaScript malware on the end.

http://victim/promo?product_id=100&title=Foo#

As before, this URL can be manipulated to SRC in additional JavaScript malware from any location on the Web. What makes this style of XSS different, is that the JavaScript malware payload does not get sent to the Web server. As defined by Request For Comment (RFC), the “fragment” portion of the URL, after the pound sign, indicates to the Web browser which point of the current document to jump to. Fragment data does not get sent to the Web server and stays within the DOM. Hence the name, DOM-based XSS.

Persistent (or HTML Injection) XSS attacks most often occur in either community contentdriven Web sites or Web mail sites, and do not require specially crafted links for execution.A hacker merely submits XSS exploit code to an area of a Web site that is likely to be visited by other users.These areas could be blog comments, user reviews, message board posts, chat rooms, HTML e-mail, wikis, and numerous other locations. Once a user visits the infected Web page, the execution is automatic.This makes persistent XSS much more dangerous than non-persistent or DOM-based, because the user has no means of defending himself. Once a hacker has his exploit code in place, he’ll again advertise the URL to the infected Web page, hoping to snare unsuspecting users. Even users who are wise to non-persistent XSS URLs can be easily compromised.

DOM is a World Wide Web Consortium (W3C) specification, which defines the object model for representing XML and HTML structures. In the eXtensible Markup Language (XML) world, there are mainly two types of parsers, DOM and SAX. SAX is a parsing mechanism, which is significantly faster and less memory-intensive but also not very intuitive, because it is not easy to go back to the document nodes (i.e. the parsing mechanism is one way). On the other hand, DOM-based parsers load the entire document as an object structure, which contains methods and variables to easily move around the document and modify nodes, values, and attributes on the fly.

Browsers work with DOM. When a page is loaded, the browser parses the resulting page into an object structure.The getElementsByTagName is a standard DOM function that is usedto locate XML/HTML nodes based on their tag name. DOM-based XSS is the exploitation of an input validation vulnerability that is caused by the client, not the server. In other words, DOM-based XSS is not a result of a vulnerability within a server side script, but an improper handling of user supplied data in the client side JavaScript. Like the other types of XSS vulnerabilities, DOM-based XSS can be used to steal confidential information or hijack the user account. However, it is essential to understand that this type of vulnerability solely relies upon JavaScript and insecure use of dynamically obtained data from the DOM structure.

Here is a simple example of a DOM-base XSS provided by Amit Klein in his paper “Dom Based Cross Site Scripting or XSS of the Third Kind”:

Hi


Welcome to our system…

If we analyze the code of the example, you will see that the developer has forgotten to sanitize the value of the “name” get parameter, which is subsequently written inside the document as soon as it is retrieved. In the following section, we study a few more DOM based XSS examples based on a fictitious application that we created.

Let’s walk through the process of identifying DOM-based XSS vulnerabilities using a fictitious Asynchronous Javascript and XML (AJAX) application.

First, we have to create a page on the local system that contains the following code:

Awesome

awesome ajax application

Please, enter your nick and presschat!

Awesome AJAX Application

Next, open the file in your browser (requires JavaScript to be enabled).The application looks like that shown in Figure 1.3

Once the page is loaded, enter your name and press the Chat button.This example is limited in that you cannot communicate with other users.We deliberately simplified the application so that we can concentrate on the actual vulnerability rather than the application design. Figure 1.4 shows the AJAX application in action.

Notice that this AJAX application does not need a server to perform the desired functions. Remember, you are running it straight from your desktop. Everything is handled by your browser via JavaScript and jQuery.

** jQuery is a useful AJAX library created by John Resig. jQuery significantly simplifies AJAX development, and makes it easy for developers to code in a cross-browser manner.**

If you carefully examine the structure and logic of the JavaScript code, you will see that the “Awesome AJAX application” is vulnerable to XSS.The part responsible for this input sanitization failure is as follows:

$(this).html('

Welcome ' + name + '! You can type your message into the formbelow.

');

As seen, the application composes a HTML string via JQuery’s HTML function.The html function modifies the content of the selected element.This string includes the data from the nickname input field. In our case, the input’s value is “Bob.” However, because the application fails to sanitize the name, we can virtually input any other type of HTML, even script elements, as shown on Figure 1.5

If you press the Chat button, you will inject the malicious payload into the DOM.This payload composes a string that looks like the following:

Welcome

! You can type your message into the form below.

This is known as non-persistent DOM-based XSS. Figure 1.6 shows the output of the exploit.

Credits : Rsnake, Article already published in Rsnake's Book