8

With the introduction of the HTTP X-XSS-Protection header it seems to me that the vulnerability impact (read: amount of possibly affected users with modern browsers) is drastically reduced.

Firstly, does this mean that when the X-XSS-Protection header is properly set and that when the browser's XSS protection is enabled, the web developers don't need to worry about XSS anymore (at least for the visitors with modern browsers)? Which could be as simple as "We don't support browsers X, X and X and versions X and lower.".

Secondly, what (popular) browsers implemented this security feature, is it enabled by default, and since what version or on what date was that version released?

Thirdly, are there known bypasses of that browser's XSS filter?

  • 8
    Browser XSS filters don't protect against stored XSS. There have been various bypasses as well, like this. While the bypasses tend to get fixed, the general reckoning is that a determined attacker can still get past them. – paj28 Jun 25 '16 at 16:49
  • 1
    X-XSS-Protection will not end-of-life XSS, however Content Security Policy has the power to do this, should it be properly configured. It will not end-of-life it's cousin HTML injection though, although it can severely restrict the impact. – SilverlightFox Jun 27 '16 at 15:58
19

Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header?

No. X-XSS-Protection is only used to enable or disable the inbuilt filtering[*] - which is generally enabled by default anyways.

So a more fitting question would be if XSS reached its end-of-life with browser filters.

But again, the answer is no. XSS is still a danger, because of three reasons:

  • Persistent XSS is not affected by browser filtering at all, as the browser has no way of knowing what is user input and what isn't.
  • Some browsers do not have filters against XSS, for example Firefox. XSS vulnerabilities are introduced server-side and web developers should not rely on browser vendors defending against them.
  • Bypassing of browser filters: XSS is context sensitive, which makes it very difficult to defend against without knowing the context (which is also why XSS should be defended when outputting data, not via some generic input filter).

The bypassing can basically happen because of two reasons:

  1. There is a bug in the filter.
  2. The user input is echoed in a location where filtering is not practical. One example would be <script>[userinput]</script>.

[*] As the header is not defined in any RFC, it is difficult to say how browsers will react. For example, Chrome 51 will disable its filter if the header is set to 0, but it will not re-enable the filter in case the user disabled it if 1 is set. Other browsers may behave different.

Which could be as simple as "We don't support browsers X, X and X and versions X and lower.".

It's really not that simple. Especially large organizations are notoriously bad at updating. Depending on your website, you can't just say that you don't support browsers X.

Secondly, what (popular) browsers implemented this security feature, is it enabled by default, and since what version or on what date was that version released?

X-XSS-Protection is supported by IE, Chrome, and Safari.

Chrome had an XSS filter since 2010 (Chrome 4). It was disabled by default in the same year, and then re-enabled in Chrome 8.

IE had an XSS filter since 2008 (IE 8).

Firefox doesn't have a filter, the NoScript plugin does though.

Thirdly, are there known bypasses of that browsers XSS filter?

Yes. Of course. There are more. Most depend on some specific situation (eg input is echoed in two locations). The IE8 filter actually introduced an XSS vulnerablity, even into sites that did not contain one.

  • 1
    To add to this- besides using simple and ineffective blacklisting, the web browser has no way to identify malicious, XSS-causing JavaScript versus JavaScript that is intended to be a part of the website. – multithr3at3d Jun 25 '16 at 18:56
  • 1
    Are you sure X-XSS-Protection: 1 will enable the filter if disabled by the user? Also you could add that 1; mode=block offers better protection because it prevents the whole page being rendered should a reflective XSS attack be detected, and this would also mitigate attacks like the one with the IE8 filter because nothing will be rendered if this is attempted. – SilverlightFox Jun 27 '16 at 15:55
  • @SilverlightFox Thanks for the question and comment regarding block mode. Based on everything I read, it should re-enable the filter. But I tried it with Chrome 51, and it did not work (0 does disable the filter though), I can't test IE right now. – tim Jun 27 '16 at 16:42
0

Actually, even if that header could solve the problem, the second part is a human factor: the hosters/developers/webmasters are about to use it, actually...

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.