10

I knew that XSS attacks (“non-persistent” and “persistent”) can hijack user session, deface websites, conduct phishing attack, etc.

However, I can't understand what is dangerous of DOM Based XSS if its not able to (Hijack session, click jacking, etc)?

I reviewed OWSAP DOM Based XSS and also This Page that outlines these two notes:

  1. The malicious payload was not embedded in the raw HTML page at any time (unlike the other flavors of XSS).

  2. This exploit only works if the browser does not modify the URL characters. Mozilla automatically encodes < and > (into %3C and %3E, respectively) in the document.

Then, what kind of attack (XSS DOM Based) Can accomplish?

1

2 Answers 2

14

Cross-site scripting is cross-site scripting -- the difference between DOM/persistent/reflected is only in how the attack is done (and prevented).

The threat is the same -- an attacker somehow has injected malicious javascript into pages that they shouldn't be able to control, usually due to vulnerabilities in the design of the website.

Take the example from OWASP, where the HTML page, included some inline javascript (part inside the tags). The purpose of the inline javascript was to a variable from the "default" query parameter and use the value of it to modify the DOM -- that is change the value of the first <option> tag to the value of that query parameter.

The webpage source (sent over the network) looked like:

Select your language:
<select><script>    
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");    
document.write("<OPTION value=2>English</OPTION>");    
</script></select>

but after being viewed from http://www.some.site/page.html?default=French, the DOM would become:

Select your language:
<select>    
<OPTION value=1>French</OPTION>
<OPTION value=2>English</OPTION>
</select>

Meaning your web browser treats the webpage like the above was sent over the network once its run the DOM-modifying javascript (the calls to document.write).

Now a clever attacker then sends a link (via email/webpage link) that a victim clicks pointing to http://www.some.site/page.html?default=<script>alert(document.cookie)</script>. Then the webpage on the page (after processing the initial javascript with the document.write) looks like:

Select your language:
<select>    
<OPTION value=1><script>alert(document.cookie)</script></OPTION>
<OPTION value=2>English</OPTION>
</select>

Again alert(document.cookie) could be whatever arbitrary javascript the attacker wants.

Maybe there's a secret username/password or session cookie or credit card number on the page, and instead of alert you bind pressing the submit button to an ajax call so that when the user presses submit, it sends all the secret data to a server that the attacker can access.

There isn't really one worst-case scenario -- any action you can do with javascript you should be able to do if there is a DOM-XSS vulnerability.

5
  • +1: I didn't realized that Now a clever attacker then sends a link...
    – Akam
    Mar 10, 2013 at 8:50
  • Then, The only possibility of this attack is when the page uses part of the URI using DOM (JavaScript) i.e the malicious content is not part of the response.
    – Akam
    Mar 10, 2013 at 10:42
  • 1
    @Akam - Yes, if the malicious content is already in the DOM sent in the response, they don't call it DOM-based XSS. DOM-based XSS relies on the DOM getting modified, inserting attacker controlled unsafe content after it was initially sent without proper safeguards.
    – dr jimbob
    Mar 10, 2013 at 17:57
  • Interesting answer. What about a vulnerability in a strongly authenticated website? Unless I am missing something, the attacker must be the authenticated user and he can only target himself?
    – ForguesR
    Feb 15, 2016 at 13:55
  • @ForguesR - No, if the webpage is poorly designed with flaws like document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");, and an attacker can trick a user to click their link (with a malicious <script>), then the attack works even with strong authentication. (That is user clicks malicious link, authenticates with the website, and then the javascript executes in the background sending information to the attacker; e.g., if the attacker has a separate server listening for secret info to be sent to them via javascript).
    – dr jimbob
    Feb 15, 2016 at 16:33
1

DOM XSS are as dangerous as reflected XSS. To exploit it the attacker always needs to induce a client to create a request (f.e. by clicking some link that still points to the considered safe site). After this has been done, you can execure JavaScript on the client's browser. This can lead to all sort of attacks on the browser!

1
  • If the attack inserts stuff after # in the URL, it can be said that it's even more dangerous because the server logs would now show nothing.
    – Pacerier
    Jan 26, 2016 at 18:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .