Posted By Maher Bro
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.
I am here with a great news for those who hate their Facebook timeline style. I also don't like it so much. Great news is from now you can completely remove or deactivate your timeline.
. You just have to download and Follow these simple steps 
. I suggest you to choose 
