Researcher demonstrates how filter-by-default can introduce further problems for user security
Chrome’s XSS Auditor can be abused to allow exfiltration of information, thanks to Google’s decision to revert back to using ‘filter’ mode as default.
The browser’s anti-cross-site scripting technology previously blocked pages that were showing malicious code, but in a recent update (v74.0.3729.108 – the latest version) the default setting was changed to filter out these pages instead.
This means that the page is shown, but that dangerous code is now filtered to prevent certain elements from executing.
Google’s decision to revert back to filter-by-default follows the publication of fresh research that demonstrated how block mode could be abused by attackers to exfiltrate information through so-called cross-site leak (XS-Leak) exploits.
Following the changes, however, one security researcher has shown how the filter function can also be abused, due to its nature of selectively disabling scripts on a page.
Security enthusiast and bug hunter terjanq found that he was able to exploit XSS Auditor by bypassing the DOM Validator.
During a recent capture the flag challenge, the researcher used an unstable version of Google Chrome with filter mode enabled by default, on a website without an X-XSS-Protection header.
He wasn’t able to filter out the DOMValidator.js script as it was loaded by the same domain, but he could filter the sha512.js script.
The DOMValidator.js used the =CryptoJS.SHA512 ()= function – meaning that by causing XSS Auditor to filter the sha512.js JavaScript file, it removed the function causing a call to the function to fail and therefore bypassing the protection mechanism.
He effectively tricked Chrome into believing that non-malicious script was attempting to execute XSS, allowing him to bypass code that implements security measures, and execute script that he had inserted causing XSS.
“Saying that I discovered something in here wouldn’t be fair to many researchers,” he told The Daily Swig.
“The issue I have briefly described was known and researched for several years. The core concept of the issue is to remove any unwanted script from the attacker’s perspective as a way to introduce the XSS vulnerability on websites whose protection against it relies on these scripts.
“In 2016, Google Chrome switched the default XSS Auditor mode from filter to block as a way to prevent the attacks described at the time. A good collection of these issues can be found here.
“Over [the] last years, the block mode as a default seemed to be fulfilling its role and indeed was a great protector of vulnerable websites. Unexpectedly, recent research proved it wrong and exposed it to new vectors also known as cross-site leaks (XS-Leaks).
“But now, with Google reverting the old fix it looks like many people have forgotten how dangerous the filter mode was, so I decided to briefly refresh the knowledge collected over the years.”
Google’s decision to revert back to filter mode was surprising, noted terjanq, given that the impact is more dangerous.
He added: “While the XSS Auditor provides another layer of security for websites that are vulnerable to cross-site scripting, unfortunately it also ends up introducing several leaks that wouldn't happen otherwise.
“These are really hard to fix, because of the nature of the Auditor. Even after the recent change the Chrome team did – from block to filter mode – not all leaks were fixed and known attack vectors were reintroduced, as I demonstrated in my article.
“So, yes, I do think that the Auditor should follow the same steps as other browsers and be disabled by default. If any website wants to rely on the browser's protection they should request it at their own, but with full awareness of the implications that the Auditor brings.
“Also, disabling XSS-Auditor seems to be the path that Facebook, and more recently Google (in their web services) chose to follow.”
The Daily Swig has reached out to Google for comment.
RELATED New XS-Leak techniques reveal fresh ways to expose user information
