9

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?

Akam
  • 1,327
  • 3
  • 14
  • 23
  • Related: http://security.stackexchange.com/a/73745/2379 and http://security.stackexchange.com/q/52870/2379 – Pacerier Jan 26 '16 at 17:59

2 Answers2

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.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • +1: I didn't realized that `Now a clever attacker then sends a link...` – Akam Mar 10 '13 at 08: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 '13 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 '13 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 '16 at 13:55
  • @ForguesR - No, if the webpage is poorly designed with flaws like `document.write("");`, and an attacker can trick a user to click their link (with a malicious ` – dr jimbob Feb 15 '16 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!

DavidC
  • 51
  • 3
  • 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 '16 at 18:00