[dansingerman]

"Single Page Apps increase the amount of client side logic and user input processing. This makes them more likely to be vulnerable to DOM-based XSS, which, as previously mentioned, is very difficult for website owners to detect."

Hmmm...assuming your back end has all the requisite validation and other security in place, how can a SPA cause an XSS? Are there any purely client side attack vectors (XSS or otherwise) that need to be considered if your back end is fully protected?

[airza]

Yes, a very common dom-based XSS vector is against document.hash, which is never passed to the server. Versions of Adobe Robohelp keep getting pwned by this. The article is kind of wrong that attacks against the URL won't be detected by the server since a decent WAF will detect this.

[patcheudor]

>a decent WAF will detect this.

Nope, nope, and nope. In a DOM based attack via a GET request, an attacker can place the payload after a hash (the pound, ergo anchor reference): http://foobar.whatever/foo?bar=tender#<XSS VECTOR>

No browser sends either # or anything after it to the server, thus the only way to detect this attack is to have some active script in the DOM which sends the document.location to the server but of course if the attacker knows about that and if they can get to the DOM before that script, well, it's over.

[airza]

That is what I said in the first sentence of the post you are replying to. If it is not clear from that, I am referring to the non-fragment part of the URL.

[coderzach]

Imagine a link like this:

https://example.com/login?vulernable-param=evilcredentialste...

If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.

[airza]

Yes, but that gets passed to the server.

[sbarre]

It may get logged by the server but if it's designed to be parsed client-side, there may not be any server-side code examining or sanitizing that value before the SPA gets to it.

[ghayes]

What about httsp://example.com/login#vulnerable-fragment

[airza]

Yes, as i commented elsewhere in this thread that would be fine.

[knowaveragejoe]

Wouldn't evilCredntialStealingJavascript() have to be stored on the server in the first place...?

[thephyber]

No.

DOM-based XSS is when JavaScript running on the client takes data from a "source" (URL parameter, DOM content, cookie, LocalStorage, etc), manipulates it, and then executes it on a "sink" without properly escaping it. Examples of "sources" and "sinks"[1].

I've reported DOM-based XSS on a website that parses user-generated comments for URLs then converts the comment by adding hyperlink markup to the URL. It was done insecurely, so I managed to use combinations of spaces and other HTML attribute delimiters to inject an "onMouseOver" attribute and collect a bounty (about $2000 IIRC). In my case, the payout was large because the data was stored on the server (therefore it was persistent XSS), but with URL fragments, it's possible for the server to never see the content that is passed to the "source".

[1] https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...

[marcosdumay]

It needs to be echoed into somewhere on the page. Not necessarily stored on the server.

[_xgw]

Reflected XSS attacks