2

Simple question but hard to understand how web browsers make the distinction between legitimate and malicious code when mode=block is enabled?

Of course, I would like to know how each rendering engine works.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
user2284570
  • 1,402
  • 1
  • 14
  • 33

2 Answers2

4

You can read up about the Chromium XSS Auditor here. Basically, it checks to see if client-side code was reflected from the URL query. For instance, the following page contains a legitimate piece of code that creates an alert box (<script>alert('123456');</script>). The XSS Auditor will trigger if you navigate to the same page but with the code snippet in the URL, because the Auditor assumes that the "payload" was reflected from the URL query:

http://webdbg.com/test/xss/alert12345-mode1block.aspx?%3Cscript%3Ealert(%2712345%27)%3B%3C%2Fscript%3E

enter image description here

Try changing 12345 to something else and observe how the Auditor now renders the page because the alert()s' values no longer match.

The comments in the XSS Auditor's source code are particularly helpful in getting a better understanding of how it can tell legitimate and malicious code apart, most notably the following comment:

// If the resource is loaded from the same host as the enclosing page, it's
// probably not an XSS attack, so we reduce false positives by allowing the
// request, ignoring scheme and port considerations. If the resource has a
// query string, we're more suspicious, however, because that's pretty rare
// and the attacker might be able to trick a server-side script into doing
// something dangerous with the query string.

This also indicates why the XSS Auditor does not prevent stored XSS payloads from executing.

EdOverflow
  • 1,246
  • 8
  • 21
  • and for other rendering engines ? Also what about xss inside style elements ? – user2284570 Jan 09 '19 at 18:15
  • The XSS Auditor I referred to above that is part of WebKit is the only remaining modern Auditor worth mentioning since Firefox does not ship with one and Edge is planning on discontinuing their in-built XSS filter: https://textslashplain.com/2018/11/06/an-update-on-the-edge-xss-filter/. Internet Explorer used a regular expression-based approach, but that failed miserably as covered in http://www.collinjackson.com/research/xssauditor.pdf. – EdOverflow Jan 09 '19 at 18:28
  • What do you mean by "xss inside style elements"? The reflection endpoint shouldn't matter as long as the payload was reflected from the URL query string. Of course there are ways of bypassing the Auditor, but I already covered that in https://security.stackexchange.com/questions/188998/what-is-the-xss-auditor-in-chrome-firefox-and-how-do-i-find-bypasses/198805#198805. – EdOverflow Jan 09 '19 at 18:28
  • Ok sorry. I mean inside style attributes. Edge will now turn to Google blink anyway so I’m still interested how does it behave in Edgeʜᴛᴍʟ and Trident. – user2284570 Jan 09 '19 at 18:39
  • If you break out of the style attribute to achieve reflected XSS, then the Auditor should pick that up as described above. That being said, if you are referring to scriptless attacks (https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf), then you would be right to assume that the Auditor won't detect those since that isn't the Auditor's job. You cannot achieve JS execution in the context of CSS in modern browsers as covered in https://security.stackexchange.com/a/199422/192205, so anything in the context of CSS wouldn't be considered XSS. – EdOverflow Jan 09 '19 at 19:01
1

First of all, mode=block prevents rendering the entire page when an XSS attempt is detected. This sometimes, but not always, prevents possible filter bypasses over the default mode when the offending code is simply stripped out.

The mechanism behind X-XSS-Protection is called the XSS auditor and is browser specific. As far as I am aware, different browser engines such as WebKit, Chromium, and Firefox all operate differently from each other. Generally speaking though, they operate by pattern matching the requests’ parameters for suspicious values. This, in effect, can only prevent reflection-style XSS attacks. Even still, bypasses are frequently found in all vendors so it’s not a good idea to be reliant on the auditor, but it’s good to have defense in depth.

I wouldn’t recommend using only this header nowadays. Only in combination with Content-Security-Policy.

InvokeStatic
  • 133
  • 1
  • 5
  • Sorry I see I asked the wrong question please read it again. I’m not interested at all at what happens whenever something is detected. – user2284570 Jan 09 '19 at 16:38