5 ms·
"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 p
by dansingerman 9y ago
"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?
- _xgw 9y agoReflected XSS attacks
- coderzach 9y agoImagine a link like this: https://example.com/login?vulernable-param=evilcredentialstealingjavascript() 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 9y agoYes, but that gets passed to the server.
- sbarre 9y agoIt 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 9y agoWhat about httsp://example.com/login#vulnerable-fragment
- airza 9y agoYes, as i commented elsewhere in this thread that would be fine.
- knowaveragejoe 9y agoWouldn't evilCredntialStealingJavascript() have to be stored on the server in the first place...?
- marcosdumay 9y agoIt needs to be echoed into somewhere on the page. Not necessarily stored on the server.
- thephyber 9y agoNo. 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-s3QpQtUrOkPx6t5dR3QyQo24kCVYQy7YY/edit https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...
- airza 9y agoYes, 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 9y ago>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 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.
- deleted 9y ago[deleted]
- airza 9y agoThat 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.