2

A web application takes user input and displays the data, without any escaping or encoding, in div or p tags. So if I provide <script>alert(1)</script> as input, the source would look roughly like this:

<div>
  <p><script>alert(1)</script></p>
</div>

From this I would assume that the web application is vulnerable and that the script will be executed. That is usually the case, but I have seen a few situations (can't provide any examples right now, unfortunately) where that is not the case. The payload is not executed even though it is reflected into the page.

What explanations could there be for this behaviour? Are there some other form of XSS prevention that stops unescaped scripts from being executed?

  • 3
    The built in browser console is your friend in these cases - open it, reload the page, and look at the errors that appear. Might be something like a CSP header preventing inline code from running, might be that your input is included somewhere else on the page which breaks other code, might be that your browser is "helpfully" showing your input as unencoded, when it is actually encoded in the source sent over the network. Lots of possibilities. – Matthew Nov 2 '17 at 9:11
6

I see a number of possible explanation for this mystery:

  • The browsers built in XSS protection stopped the code from being executed. Not sure if the payload would be reflected back in the document if this was the case, though. (According to Conor Mancone in Chrome the payload will be reflected in the source but highlighted in red when you choose view source.)
  • There is a Content Security Policy that stops inline scripts from being executed. Fire up the developer console, go to the network tab and see if you can find a response header named Content-Security-Policy.
  • The content is put into the document using JS. If you set the DOM elements text property (or use the jQuery .text() method) the tags vill not be interpreted as tags but also not encoded as &gt;. To see if this is the case, use view source and see if you can find your payload in the actual page source. If it is not there, it must have gotten into the document by means of JS.
  • 3
    In addition to your third point, developer tools in browsers sometimes display inner HTML contents unescaped, for display purposes. – Vivelin Nov 2 '17 at 9:53
  • Thank you both for your suggestions! The next time I come across this phenomenon, I'll make sure to check for these points. I noticed that the developer tools' inspect differs from the source code of a website - but that's a very good point as well @Vivelin! – SaAtomic Nov 2 '17 at 11:41
  • 2
    Just because I was playing around with it recently: at least for Chrome, the payload will be reflected in the document contents. It just won't be executed. It will also be highlighted red when you "view source". – Conor Mancone Nov 2 '17 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.