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.

This question already has an answer here:

I'm not a computer guy, but just out of curiosity I've recently started to learn PHP for programming my own website and I've read about some most common vulnerabilities that exist in web applications. I know the basics about Cross Site Scripting vulnerabilities. So, an XSS attack happens when the input from the user is not filtered properly and it is used in the body of the page, so attacker can inject things like javascript/vbscript codes into the browser and do stuff on the client side like hijacking their cookies and save them in a database.

But what is the difference between XSS and Dom XSS? Does there exist a fundamental difference between them? Do DOM XSS vulnerabilities pose a higher security risk? If yes, how? And how should I look for Dom XSS vulnerabilities in web applications? I find some stuff on the internet but some of them were advanced for my current level of understanding.

Thanks guys.

share|improve this question

marked as duplicate by Adnan, Polynomial, Rory Alsop Feb 21 at 11:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
@RohanDurve-Decode141: Hi Rohan, they are not duplicates. As this question focuses on the difference between ordinary XSS and DOM XSS while the one you gave doesn't explain this, it only says what XSS is, while I already know what XSS is. –  math.n00b Feb 21 at 9:27
    
That's what the 2nd answer in that post was. –  Rohan Durve - Decode141 Feb 21 at 15:45

2 Answers 2

up vote 4 down vote accepted

Ok so at a basic level there are three types of Cross-Site Scripting.

Reflected - You enter data to the application, which is then echoed back without escaping, sanitization or encoding and it's possible to include JavaScript code which is then executed in the context of the application

Stored - You enter data which is stored within the application and then returned later on in response to another request. This data contains JavaScript code which is executed in the context of the application

DOM based - You enter data which modifies the DOM of the web page, this data contains JavaScript which is executed in the context of the application. It's relatively similar to reflected XSS but the difference is that in modifying the DOM the data might not ever got to the server (which changes how it can/should be mitigated as server-side filters might not be effective).

An example would be web applications which make heavy use of client-side JavaScript and which take user data and update the DOM without ever actually sending the data to the server. If you see applications which make instant changes to the page you're viewing when you enter data, it's likely that they're using client-side JavaScript to update the DOM.

In terms of finding them, that's kind of tricky, as the tools to find DOM based XSS aren't as developed as the ones for Reflective or Stored XSS. The only tool which specifically addresses it, which I'm aware of is Dominator. There's also information on the DOM XSS Wiki which could be useful.

share|improve this answer
    
Good answer. Should clarify that "stored / reflective" and "DOM based / normal" are orthogonal. You can have "stored DOM XSS" and "reflective DOM XSS". So there are four types :-) –  paj28 Feb 21 at 11:17
    
Well, I understand reflected and stored XSS attacks. I guess my problem with understanding DOM XSS is that I don't know what DOM means. Can you please explain what Document Object Model is in layman terms? –  math.n00b Feb 21 at 11:42
    
@N1CK that's a kind of long topic and not really a Sec.SE one. in essence it's usually a means of manipulating HTML documents programatically some good info here developer.mozilla.org/en/docs/DOM –  Rоry McCune Feb 21 at 11:52

Simply put, DOM-based XSS can be exploited without the client requesting the server. The attack takes place in the DOM which is local (in the user context).

For a developer to find and correct those, this is complicated as of today no mature technology exist to detect those vulnerabilities. Some programs and scripts are used but this is still very "work in progress", even the mentioned "Dominator" software (which, by the way, is far too expensive for what it does IMO).

share|improve this answer

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