Given that I categorize XSS in a matrix of {client,server}x{stored,reflected} and treat DOM XSS as a subset of client XSS, can there be a reflected client XSS which is not DOM based? I cannot find or think of an example because all reflected values I can think of are accessed using DOM methods.
-
Suggest move to StackOverflow, you will get better answers there...– ISMSDEVCommented Jun 21, 2017 at 8:31
-
@ISMSDEV: I disagree, this seems perfectly on-topic here.– SilverlightFoxCommented Jun 21, 2017 at 9:30
-
@SilverlightFox I was mearly suggesting the OP may get a better response. Wasn't saying he had to move it.– ISMSDEVCommented Jun 21, 2017 at 9:51
-
@ISMSDEV And I was disagreeing. ;-) I'm just saying security professionals will be better placed to comment on cross-site scripting rather than programmers, as a programmer's priority is of functionality rather than security.– SilverlightFoxCommented Jun 21, 2017 at 9:56
-
@SilverlightFox - Retracted move. Great answer. You could equally be a developer and a security pro, but yes I get your point.– ISMSDEVCommented Jun 21, 2017 at 9:57
1 Answer
From those categorisations:
Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call.
(em mine)
Therefore for it to be client XSS, it has to involve updating the DOM.
Although, the article goes on to say:
DOM Based XSS is simply a subset of Client XSS
I believe this is referring to the actual source being from the DOM rather than the server.
e.g.
foo.innerHTML = document.location.hash;
Rather than
foo.innerHTML = ajaxResult;
This is because the definition of DOM based XSS is as follows:
DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.
So reflected client based XSS which is not DOM based is where the data itself is from the server (reflected in the response from the HTTP request), but the code is rendered on the page via JavaScript.
Example:
Request:
http://example.com?name=<svg onload=alert(1) />
(Name would be % encoded, but I've left it unencoded here for clarity.)
Response:
<script>
var name = "<svg onload=alert(1) />";
$('#output').html(name);
</script>
<div id="output">
</div>
Takeaways
What is probably important when it comes to XSS is the following:
- Any type of stored XSS is mostly higher risk than any form of reflected XSS. Browser XSS filters cannot stop them (except if a Content Security Policy is in place and is sufficiently locked down).
- When an XSS updates the DOM in a reflected XSS attack, this bypasses browser XSS filters too (same caveats in regards to CSP).
- Server reflected XSS is less risky as it requires user interaction and there's also a good chance a browser XSS filter will block it.
-
I disagree with your source on "Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call." because that definition does not include
eval
and related calls, which do not update the DOM but are client XSS. However, thank you for the reflected example. For a stored (non-DOM) client XSS I already had the AJAX call as an example. Commented Jun 21, 2017 at 12:16