Hey awl h0wz yuh well in diz tut i will be giving uhh awl a brief xplanation on DOM based XSS attacks :) :)
I will not be gng 2 deep cz its quite confusioning i will be posting abt it in detail later :D although m also working on it dese days :P
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)
 |  |
| Fig 1.2 | Fig 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
Example 1
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.
Example 2
<script>
var url = window.location.href;
var pos = url.indexOf("title=") + 6;
var len = url.length;
var title_string = url.substring(pos,len);
document.write(unescape(title_string));
</script>
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.
Example 3
http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS%20Testing')
</SCRIPT>
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.
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”:
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf(“name=”)+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>
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.
Identifying DOM-based XSS Vulnerabilities
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:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet"
href="http://www.gnucitizen.org/styles/screen.css" type="text/css"/>
<link rel="stylesheet"
href="http://www.gnucitizen.org/styles/content.css" type="text/css"/>
<script src="http://jquery.com/src/jquery-latest.pack.js"
type="text/javascript"></script>
<title>Awesome</title>
</head>
<body>
<div id="header">
<h1>Awesome</h1>
<p>awesome ajax application</p>
</div>
<div id="content">
<div>
<p>Please, enter your nick and press
<strong>chat</strong>!</p>
<input name="name" type="text" size="50"/><br/><input
name="chat" value="Chat" type="button"/>
</div>
</div>
<script>
$('[@name="chat"]').click(function () {
var name = $('[@name="name"]').val();
$('#content > div').fadeOut(null, function () {
$(this).html('<p>Welcome ' + name + '! You can
type your message into the form below.</p><textarea class="pane">' + name + ' >
</textarea>');
$(this).fadeIn();
});
});
</script>
<div id="footer">
<p>Awesome AJAX Application</p>
</div>
</body>
</html>
Next, open the file in your browser (requires JavaScript to be enabled).The application looks like that shown in Figure 1.3
 |  |
| Fig 1.3 | Fig 1.4 |
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('<p>Welcome ' + name + '! You can type your message into the form
below.</p><textarea class="pane">' + name + ' > </textarea>');
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
 |  |
| Fig 1.5 | Fig 1.6 |
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:
<p>Welcome <script>alert('xss')</script>! You can type your message
into the form below.</p><textarea class="pane"><script>alert('xss')
</script> > </textarea>
This is known as non-persistent DOM-based XSS. Figure 1.6 shows the output of the exploit.
.jpg)
