XSS Auditors – Abuses, Updates and Protection
Google recently updated how the XSS Auditor works on the Chrome cross-platform web browser. This article explains what XSS Auditors are. It then describes how XSS Auditors work and how hackers abuse them to bypass security mechanisms. It finally provides two methods on how to protect yourself against XSS Auditor abuses.
Your Information will be kept private.
Your Information will be kept private.
XSS Auditors are security mechanisms in browsers that operate as a preventative layer against Reflected Cross-site Scripting attacks. Each browser has a different way of implementing XSS Auditors. In this blog post, we discuss Google Chrome’s recent update that changes how the XSS Auditor behaves, and the different ways in which attackers have been able to abuse this mechanism both before and after the update. We conclude by suggesting two methods for protecting yourself against XSS Auditor abuses.
How XSS Auditors Work
The security offered by XSS Auditors lies in their ability to intercept dangerous input that can result in JavaScript code execution in the requested URL on the page. When dangerous HTML code in the URL matches HTML code on the page, its embedded script code is not executed.
At this point, it is important to point out that XSS Auditors only prevent Reflected XSS from being exploited. They do not prevent Stored XSS, DOM XSS, mXSS, or similar XSS attack types.
In this code sample, when the browser detects that the value in the query string is reflected on the page, it will stop the reflected code from executing on the page.
Request:
http://www.example.com/?param=<script>alert(1);</script>
…
Response:
…
<div>
<script>alert(1);</script>
</div>
…
Browsers stop the execution of reflected code in two ways:- By making sure the code block is kept inactive
- By blocking the entire page from loading
The browsers’ preferences on this matter vary. For example, the Edge browser keeps the XSS Auditor mechanism inactive. This means that Edge browsers do not intercept the script behavior. You need to activate the XSS Auditor mechanism by setting an X-XSS-Protection header. X-XSS-Protection security headers were introduced to browsers, beginning with Internet Explorer 8, in 2008. It’s a security header that helps us control the behavior of XSS Auditors.
For further information on security headers, see Whitepaper: HTTP Security Headers and How They Work.
Google Chrome’s Recent XSS Auditor Update
A recent update was released by Google about changes to the XSS Auditor behavior in Chrome. Since 2016, the XSS Auditor blocked the entire page from loading in the presence of a Reflected XSS vulnerability.
With the release of Chrome 74 in April 2019, XSS Auditors began to block particular script code from executing, instead of the entire page. Here is an example:
<html>
<head>
</head>
<body>
<h1>hello world!</h1>
</body>
<script>document.body.innerHTML+= "<div>I am a block, attacker wants to prevent</div>";</script>
<script>document.body.innerHTML+= "I am another block";</script>
</html>
An attacker might be able to abuse this feature to block particular code from loading on the page.
Abusing XSS Auditors to Bypass Security Mechanisms
It was known in the security community that attackers employed XSS Auditors to disable code on websites. They achieved this by using the auditors mechanism to block the matching code in the query string from loading on the page.
In the past, XSS Auditors were used for far more advanced bypass techniques. For example, a researcher called ‘terjanq’ wrote about how he managed to solve a CTF challenge by abusing Chrome’s recent update of XSS auditors. For this reason, he considers XSS Auditors as both protectors and deceivers of the protected.
Attackers also used XSS Auditors to block the Frame Buster mechanisms on pages. Here is a sample scenario showing how they might do this.
If developers knew that a website was loaded within an iframe, they might be able to redirect the entire tab to their website using the code below:
<script>
if(top != self) {
top.location = self.location;
}
</script>An attacker could bypass this using the XSS auditor using the code below:
<iframe src="http://www.victim.com/?v=<script>if">
Due to this and many other similar attacks, Edge browsers made XSS auditors inactive. Chrome browsers decided instead to filter out the code blocks instead of preventing the loading of the entire page. This could potentially result in many more bypass write-ups.
Many researchers argue that the Content Security Policy (CSP) header is advanced enough to replace the X-XSS-Protection header and similar mechanisms. This is the position of Frederik Braun in an article about how Chrome’s switching of the XSS Auditor to ‘filter’ mode enables previous attacks. Many other blog posts were published expressing concerns about Chrome’s recent update.
How to Protect Yourself Against XSS Auditor Abuses
There are a few configurations you can set in order to be safe from attackers abusing the XSS Auditor in order to block certain code on your web pages.
Method 1: The X-XSS-Protection Header
You can activate XSS Auditors using the X-XSS-Protection header by activating the ‘block’ mode.
X-XSS-Protection:1; mode=block;Method 2: The X-Frame-Options Header
You can also block your web pages from loading within an iframe using the X-Frame-Options header, or the frame-ancestors directive of the Content Security Policy (CSP) header.
X-Frame-Options: DENY; The page must not be embedded into another page within an iframe or any similar HTML element.
X-Frame-Options: SAMEORIGIN; The website can only be embedded in a site that’s paired in terms of Same Origin Policy (SOP), scheme, hostname and port. You can read about this in our whitepaper Whitepaper: The Definitive Guide to Same-origin Policy.
CSP’s frame-ancestors directive specifies the websites that have the authority to load the current page in a frame, iframe, object, embed, or applet tag. This setting shows that the page can be loaded within an iframe on the same domain pages.
Content-Security-Policy: frame-ancestors 'self'Web Application Security is a Complex Task
Chrome’s decision, to revert the default behaviour of Cross-site Scripting Filters to a standard they judged to be less secure before, shows how complex web application security can become. It is difficult to get it right, even for developers of the browsers on which the code runs. But although browsers implement security mechanisms in different ways, certain precautionary security headers will prevent attackers from gaining easy control over web applications.
- Instead of having to decide which of the X-XSS-Auditor settings are the secure choice for your application, you might want to consider enabling a strong CSP directive.
- Additionally, you can refer to our whitepaper on HTTP Security Headers and How They Work in order to get a better overview of all the available solutions in order to make an informed decision.
Further Reading
Intent to Ship: Changes to the XSS Auditor
XSS-Auditor — the protector of unprotected and the deceiver of protected.
Chrome switching the XSSAuditor to filter mode re-enables old attack
Announcing Windows 10 Insider Preview Build 17723 and Build 18204
