Update: In July 2019, Chrome developers announced that they are going to remove XSSAuditor. You can follow their bug tracker here.
Recently, Google Chrome changed the default mode for their Cross-Site Scripting
filter XSSAuditor from
filter. This means that instead of
blocking the page load completely, XSSAuditor will now continue rendering the
page but modify the bits that have been detected as an XSS issue.
In this blog post, I will argue that the filter mode is a dangerous approach by re-stating the arguments from the whitepaper titled X-Frame-Options: All about Clickjacking? that I co-authored with Mario Heiderich in 2013.
After that, I will elaborate XSSAuditor's other shortocmings and revisit the history of back-and-forth in its default settings. In the end, I hope to convince you that XSSAuditor's contribution is not just neglegible but really negative and should therefore be removed completely.
Now we have your website. The content of the code parameter above is part of your website anyway - no injection here, just a match between URL and site content:
<!doctype html> <h1>HELLO</h1> <script src="/js/security-libraries.js"></script> <script> // assumes that the libraries are included </script>
The effect is compelling. The load of the security libraries will be blocked by Chrome’s XSS Auditor, violating the assumption in the following script block, which will run as usual.
Existing and Future Countermeasures
So, as we see defaulting to
filter was a bad decision and it can be overriden
X-XSS-Protection: 1; mode=block header. You could also disallow
websites from putting you in an iframe with
X-Frame-Options: DENY, but it
still leaves an attack vector as your websites could be opened as a top-level
Cross-Origin-Opener-Policy will help, but does not yet
ship in any major browser). Surely, Chrome might fix that one bug and stop
onerror from internal error pages
But that's not enough.
Other shortcomings of the XSSAuditor
History of XSSAuditor defaults
Here's a rough timeline
- 2010 - Paper "Regular expressions considered harmful in client-side XSS
filters" published. Outlining design of the XSSAuditor, Chrome ships it
with default to
- 2016 - Chrome switching to
blockdue to the attacks with non-existing injections
- November 2018 - Chrome error pages can be observed in an iframe, due to
onerrorevent being triggered twice, which allows for cross-site leak attacks .
- January 2019 (hitting Chrome stable in April 2019) - XSSAuditor switching
Taking all things into considerations, I'd highly suggest removing the XSSAuditor from Chrome completely. In fact, Microsoft has announced they'd remove the XSS filter from Edge last year. Unfortunately, a suggestion to retire XSSAuditor initiated by the Google Security Team was eventually dismissed by the Chrome Security Team.
Thanks to Mario Heiderich for providing valuable feedback: Supporting arguments and useful links are his. Mistakes are all mine.