Is window.location = window.location susceptible to XSS

Question

This question is relating to the code window.location = window.location as a method to refresh the page and is not concerned with redirections / other variables.

My understanding is as follows:

window.location = window.location causes the page to refresh, as the browser will navigate to the same location the user is already on.

Any change to this variable via DOM manipulation will cause the page to reload/load the attackers page, thus these lines will not able to be executed with an altered value and so are not a candidates for cross site scripting attacks.

Is this correct?

Edit: What I'm really asking is if there is a way to change window.location without causing a page reload, so that then when the window.location = window.location call is made, the browser will be sent to another location.

Solution 1

So if I understand what you were asking correctly, none of these answers are correct. It is possible to leverage the window.location to perform xss. It seemed like the roadblock you were running into was with the fact that after the window.location line executed the page would refresh and skip the execution of yourpayload. I'm assuming that you are able to somhow introduce contents into a string on the right side of window.location, and the input is not being properly encoded as a JavaScript string.

For example if http://vulnerablewebsite/page?param=derp';alert('xss');var+a+%3d+' results in code like:

<script>
  window.location='derp';alert('xss');var a = '';
</script>

You can just leverage string concatenation to defer the assignment to window.location until after your payload has been executed. So something like:

http://vulnerablewebsite/page?param=derp'+%2B+alert('xss')+%2b+'

would result in the following code that executes your payload.

<script>
  window.location='derp' + alert('xss') + '';
</script>

This should really be in the security StackExchange though.

Solution 2

The problem has nothing to do with window.location, and everything to do with how you handle arbitrary data used in a new context.

If you take input from a URL and use it to build a new URL to redirect to, then you open yourself up for problems. Take the classic redirect page...

http://example.com/redirect?url=http%3A%2F%2Fsomethingevil

If there is JavaScript on the page that then sets window.location to the value of the query string parameter url, then the page will go to http://somethingevil.

The main way XSS is done is by allowing query string parameters to inject data into the page itself. For example, you might have a page that says "Hello Brad", where "Brad" came from the URL parameter called name. Now, suppose an attacker instead sets the URL to be name=%3Cscript%20src%3D%22http%3A%2F%2Fexample.com%2Fevil.js%22%3E%3C%2Fscript%3E. If I just inject the value of name directly into the page, then my script evil.js is going to run on that page. If instead I escape the data properly, then it can be used in the page as it will be interpreted as text.

Comments

[Milk]

What I'm really asking is if there is a way to change window.location without causing a page reload, so that then when the window.location = window.location call is made, the browser will be sent to another location.

[Brad]

@Milk I don't understand? Why would you do this, and what does it have to do with XSS?

[Milk]

The line of code in question was raised by a security scan as a potential exploit for Cross-Site Scripting through DOM manipulation. I didn't believe it was possible to exploit that line in this manner. Thus the question.

[Brad]

Oh, I wouldn't read too much into automated scanning. No, there's no problem with that, assuming there wasn't originally.

[docta_faustus]

Great answer, didn't know you could executive code before window.location redirects.