What is XSS Auditor, how does it work, and why was it removed by Google from Chrome?

Tram Ho

1. What is XSS Auditor?

XSS Auditor is an integrated function in Chrome that was created to mitigate Cross-site Scripting (XSS) attacks. Its purpose is to determine whether the query parameters contain malicious JavaScript code and, at the same time, block the response if the server’s response has been malicious payload.
XSS Auditor is enabled by default, but can be reconfigured or disabled via the X-XSS-Protection HTTP header:

  • Disable XSS auditor
    X-XSS-Protection: 0
  • Run in rewrite mode
    X-XSS-Protection: 1
  • Run in “block” mode
    X-XSS-Protection: 1; mode=block
  • Run with reporting
    X-XSS-Protection: 1; report=http://example.com/your_report_URI

2. How does XSS Auditor work?

The way XSS Auditor works is quite simple:

  • Whenever you send a request to the web server, Google Chrome will review the URL bar and content in the POST body (if any). It will look for dangerous strings that can lead to the execution of JavaScript code. These strings can be HTML tags, event handlers, external URLs, or URI schemes such as data or JavaScript.
  • However, it will not block these requests immediately. Instead, it will wait for a response from the server to check if these malicious inputs are actually reflected on the page without any censorship. Only in that case will XSS Auditor take action: stop the entire loading process of the site or delete the inserted scripts.

3. XSS Auditor Bypass

  • XSS Auditor is not perfect. In fact, bypassing XSS Auditor is so popular that it is considered a functional bug by the Chromium team and not a security issue. Over the years, many bypass cases have been reported to the Chrome development team. Some of them are very clever and require a deep understanding of HTML, JavaScript, XSS Auditor and the rending method of Chrome.
  • In addition, there are some unresolved issues in the code of XSS Auditor, typically the following example:
    • Imagine what would happen if a developer decided to remove all single quotes from the input to prevent SQL Injections. XSS Auditor will see <‘s’c’r’i’p’t’> in the input, but the server will send back <script> in the output.
    • How can Chrome be sure that the situation caused by the input contains parentheses? The same problem occurs if removing words like SELECT from input.
    • XSS Auditor is capable of detecting similar derivatives to a certain extent. But since it’s hard to expect this tool to keep up with all server-side changes, the number of false positive results can be huge.
  • The bugs that are so obvious once discovered are mostly corrected by the developer, which means that users are pretty safe with XSS, as long as they are not facing an attacker who has ants. In-depth knowledge of Cross-Site-Scripting and XSS Auditor. Although bypassing has become more difficult. But it is not impossible. Such cases were expected from the beginning.

4. Vulnerabilities caused by XSS Auditor

Disabling Scripts

  • Initially, XSS Auditor removed the malicious script by default.
  • However, this is not safe because the security features may be disabled.
  • Instead of preventing the entire page from displaying, XSS Auditor removes unsafe scripts and displays the rest of the page. The big problem is right here. The reason is that XSS Auditor cannot detect which scripts are posted on the page by the developer and which scripts are included by the attacker. All it can do is compare requests and responses.
  • Assume that the following script exists on the web page:

    • This function may contain a frame buster – a piece of code that determines whether the page will load in an iframe, somehow it will stop rendering the page – similar to the HTTP X-Frame-Options header. If an attacker wants to remove this functionality, they can insert scripts into the query.
    • XSS Auditor will see the script in the request and think they were written by the attacker. It will then remove the code snippet from the page, resulting in the security measure that the developer wants to take disabled.

Serious Information Leaks

  • Then XSS Auditor went the other way: blocking all pages in its default settings.
  • But this action is also risky because it leads to information leakage.
  • Suppose the developer places a script like this on their website:
    <script> const userSecret = 23456 </ script>

    • This site contains scripts, images, videos, fonts, …. It all takes a computable amount of time to load.
    • After the content has been downloaded, for example, in an iframe, an attacker can receive a notification, for example, via the onload event handle. Now, they can send many different payloads:
      /account?attacker=<script>const userSecret = 1 // takes some time to load
      /account?attacker=<script>const userSecret = 2 // instantly failes due to being blocked by the auditor
      /account?attacker=<script>const userSecret = 21 // takes some time to load
      /account?attacker=<script>const userSecret = 22 // takes some time to load
      /account?attacker=<script>const userSecret = 23 // fails as it's being blocked
  • In the end, Chrome decided to let XSS Auditor go back to the option of removing dangerous scripts (returning to “filter mode” instead of “block mode”) – choosing a less problematic solution than leaking information. .

5. Chrome disable XSS Auditor

On July 15, 2019, Google engineers announced their plans to remove XSS Auditor from Chrome. There are several reasons given to remove this feature:

  • The first reason is that too many bypasses have occurred in the past few years. Many bug hunters joke that you will not really be a security researcher if you have never bypassed XSS Auditor.
  • The next reason is that the creation of patches for XSS Auditor are causing holes in Chrome itself.
  • Moreover, too many false positives is also a problem. Many legitimate websites have been blocked by XSS Auditor due to false detection.


Share the news now

Source : Viblo