Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 6 down vote accepted

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:
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");    
document.write("<OPTION value=2>English</OPTION>");    

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

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

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:
<OPTION value=1><script>alert(document.cookie)</script></OPTION>
<OPTION value=2>English</OPTION>

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.

share|improve this answer
+1: I didn't realized that Now a clever attacker then sends a link... –  Akam Mar 10 '13 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 '13 at 10:42
@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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.