DOM Based Cross Site Scripting Attacks - Can you explain it to me?

[Akula]

I understand the more traditional persistant/non-persistant XSS attacks but the newer DOM based attacks are a bit more nebulous because I am not a coder.

 

I know they exploit Document Objects, but how does one place the javascript call into the document object, is it simply a variable replacement in the URI?

 

If you understand how these attacks work, can you explain it to me?

[AWW$HEEET]

cross site scripting attacks are notoriously a vBulletin weakness...

[Akula]

Right, but what I am looking for is how you actually craft the exploit. I know there is some unchecked part of the code allowing for input that has parameters... But DOM Based attacks look and feel a bit different.

[Vulcan900]

This seems to explain it at a high level.

http://www.owasp.org/index.php/DOM_Based_XSS

 

I haven't had to deal with much of this as my coding is to internal network users.

 

So I can't offer more than what is detailed in the link.

[Akula]

I started with OWASP. I guess it is like I think, just a variable called in the document string.

[excell]

Ack. Retracted. I completely misread what you were asking.

[HAOLE]

I have absolutely nothing to add to this.

[excell]

Anyway...

 

Traditional XSS is usually document-based, like if our version of VB was vulnerable and I inserted a script into this post to read cookie information stored in your browser.

 

DOM-based takes advantage of open URL's on any web server to run the malicious code. Basically a URL that accepts any input without sanitizing could be used to request a script and upon the host server not recognizing the request, sends it back to the browser where it's rendered and reads the cookie information stored in the browser. You need only trick the user into clicking on the URL, you don't need control of the app or server.

 

The app and/or server should be modified to not allow any random input.

 

Now for the advanced bit I said before...

 

Desktop apps like Adobe Reader, Microsoft Word, etc. can launch inside of a web browser making them basically an extension of the browser. An attack could take advantage of vulnerable Adobe Reader by passing a variable in the document request which would be processed by Reader and them passed to the browser and exploited. Basically, a rich web app could be used as an intermediary for an attack, where the attack would normally be blocked by the browser.

 

Does all that make sense?

[Akula]

Yup, got it. Thanks. I knew the traditional persistant and non-persistant ones.