XSS protection disappears from Microsoft Edge

#NoFilter

UPDATE (26/7) In a blog post yesterday, Microsoft confirmed it is removing XSS Filter in Edge. “We are retiring the XSS Filter in Microsoft Edge beginning in today’s [Windows 10 Insider Preview] build,” the company said. “Our customers remain protected thanks to modern standards like Content Security Policy, which provide more powerful, performant, and secure mechanisms to protect against content injection attacks, with high compatibility across modern browsers.”

XSS Filter, Microsoft’s cross-site scripting defense for its web browsers, has disappeared from Edge as a default security feature.

The discovery was made earlier this week by PortSwigger researcher Gareth Heyes, leading to questions surrounding whether the XSS Filter is broken or if Microsoft has disabled it for good.

Off by default

The HTTP X-XSS-Protection response header stops pages from loading when they detect reflected cross-site scripting attacks. In Microsoft browsers there are three options:

The ‘0’ header disables XSS filtering, while ‘1’ enables XSS filtering (usually default in browsers), with the browser sanitizing the page in the event of a suspected cross-site scripting attack.

‘1; mode=block’ enables XSS filtering, but rather than sanitizing the page the browser will completely block the page from rendering.

“The XSS Filter is supposed to be on by default,” Heyes explained. “However, it is now off by default, and even if you try to turn it on with X-XSS-Protection: 1 it remains off.

“The only way to actually turn it on now is when you have the header X-XSS-Protection: 1; mode=block.”

Heyes added: “I’ve confirmed Internet Explorer is unaffected and still continues to detect XSS attacks by default.”

Anti-XSS

XSS Filter made its debut in Internet Explorer 8 back in 2009, with Microsoft heralding the feature as a new type of defense against reflected cross-site scripting attacks.

Ahead of the its launch, former Microsoft security software engineer David Ross explained how the filter operates as an IE component with visibility into all requests and responses flowing through the browser.

“When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response,” Ross said. “Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.”

Although the filter was not designed protect against all types of XSS attacks, it was intended to raise the bar for browser security by making some common attack scenarios unfeasible.

XSS Filter was ported to Internet Explorer’s successor, Microsoft Edge, following the browser’s launch nearly three years ago.

Edge case

In the nine years since XSS Filter was first rolled out, the security component has been no stranger to controversy, as researchers successfully turned Microsoft’s frontline defense tool against itself.

Indeed, reports of vulnerabilities in XSS Filter are almost as old as the feature itself.

At Black Hat Europe 2010, researchers Eduardo Vela Nava and David Lindsay outlined how it could be abused by attackers to launch cross-site scripting attacks on websites that would otherwise be immune to this threat.

More recently, Japanese security specialist Masato Kinugawa published a major piece of research outlining numerous cross-site scripting attacks that exploit XSS Filter.

He explained: “In order to deny XSS attacks, XSS Filter looks into the request for a string resembling an XSS attack, compares it with the page and finds the appearance of it, and rewrites parts of the string if it appears in the page. This rewriting process of the string – is this done safely? The answer is no.

“I have found a way to exploit XSS filter not to protect a web page, but to create an XSS vulnerability on a web page that is completely sane and free of XSS vulnerability.”

And just this year, Xiayin Liu leveraged another vulnerability in the XSS Filter on Edge to bypass the Content Security Policy (CSP) when served from a meta element.

“This is quite ironic, because both XSS filter and CSP are designed to protect users from XSS attacks, but this vulnerability allows attackers to abuse one XSS protection mechanism to bypass another,” Liu said.

False positives

In March 2016, Hong Kong-based security specialist File Descriptor pulled focus on the Microsoft’s anti-XSS component.

Citing the results of a straw poll conducted on Twitter – in which X-XSS-Protection: 0 was voted as the least favorite approach – the researcher discussed the “security implications” of the feature and why he felt it should be off by default.

“The first problem is that it widens the attack surface,” he said in a blog post. “By abusing false positives, attackers can selectively disable innocent scripts on the page.”

Of course, the potential pitfalls of anti-XSS filters haven’t escaped the attention of Microsoft’s rival developers.

XSS Auditor, Chrome’s native defense against cross-site scripting, has not been without problems – ranging from reports of false positives to the discovery of a bypass that would allow an assailant to launch further attacks on the user.

Four months ago, Mozilla developer Frederik Braun confirmed once again the organization would not be pursuing an anti-XSS feature for Firefox.

“There have been numerous discussions… and we had come to the conclusion that it is currently not worth the effort for Firefox to provide a built-in feature,” Braun stated.

Technical documentation from Mozilla states that “these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disabled inline JavaScript”.

By turning its XSS Filter off by default, does this mark a change of direction for Microsoft – or is a bug preventing the feature from working? For the time being, it’s a guessing game.

Following numerous requests for comment, a Microsoft spokesperson said: “We have nothing to share.”

RELATED: What website are you really on? Edge zero-day leaves users with no clue