Is the payload for DOM based XSS defined to originate from only inside the browser or even outside of it

Question

I have read in multiple places contradictory views on what might be considered a DOM based XSS. It seems that the original definition says that it is a form of XSS where the payload originates exclusively from inside the browser, but some people also view it as a form of XSS where the payload may not necessarily originate from inside the browser, but is used to modify the DOM.

The second view is what confuses me. What exactly does it mean that the payload is used to modify the DOM? The OWASP page describing DOM XSS , gives an example which, to me seems to be the same as reflected XSS.

It says:

A DOM Based XSS attack against this page can be accomplished by sending the following URL to a victim: http://www.some.site/page.html?default=<script>alert(document.cookie)</script>. When the victim clicks on this link, the browser sends a request for: /page.html?default=<script>alert(document.cookie)</script>. The server responds with the page containing the above Javascript code.

The original Javascript code simply echoes it into the page (DOM) at runtime. The browser then renders the resulting page and executes the attacker’s script: alert(document.cookie)

Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

Should I interpret this as Reflected XSS means being able to injecting <script> tags in an HTML context, and DOM based XSS means being able to inject payload inside an already existing <script>?

Answer 1

DOM based XSS vs Reflected XSS

Should I interpret this as Reflected XSS means being able to injecting <script> tags in an HTML context, and DOM based XSS means being able to inject payload inside an already existing <script>?

No.

Reflected XSS means that your injected payload is reflected into the answer delivered by the server and executed by the browser (it doesn't matter where the payload is inserted, as long as it is interpreted by the browser).

With DOM based XSS, the payload may or may not be delivered in the reply of the server, but it will not be executed by the browser as-is. Instead, the JavaScript code delivered by the server will take it, and insert it into the DOM, thus leading to its execution.

DOM based XSS and Server Interaction

Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

Because the fact that it goes to the server and back is not relevant for the attack.

What is relevant for the attack is that the JavaScript delivered by the server reads out the URL and inserts it into the DOM, thus executing the injected code.

If you keep reading, OWASP also describes this:

The server responds with the page containing the above Javascript code. The browser creates a DOM object for the page, in which the document.location object contains the string:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

The original Javascript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime.
[...]
In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.

So OWASP also specifically states that a DOM based attack can go to the server and back.

Answer 2

Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

In that example, it is not going to the server to come back as XSS.

The vulnerable code is in Javascript:

<script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script>

Although in that example it does get sent to the server:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

But it doesn't have to:

http://www.some.site/page.html#default=<script>alert(document.cookie)</script>

...would also be valid for this attack. The "fragment identifier" section of the URL (#) is never sent to the server, however it can be picked up by Javascript.

In their example, it gets sent to the server but it is not the server that causes the XSS, it is the client-side code. This is what defines DOM based XSS.

To quote OWASP:

...the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.