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.
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
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:
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.
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.