Blog

With Microsoft Edge retiring the XSS Filter in July of 2018, Google Chrome is following suit and announcing the eventual deprecation of the XSS Auditor, and Firefox choosing not to implement XSS protection at all, dependence to protect your users from cross-site scripting now solely depends on you.

To understand why browsers are removing the security control, it’s important to first understand what the control did and the unfortunate shortcomings to these counter measures.

How it works

The X-XSS-Protection is a security header that can be sent to the user’s browser if the headers are configured on the server. It consists of three options that could be set depending on the specific need.

• X-XSS-Protection: 0; Disables the filter entirely. More on why this is used in the shortcomings section

• X-XSS-Protection: 1; Enables the filter but only sanitizes the malicious script

• X-XSS-Protection: 1; mode=block Enables the filter and completely blocks the page

When you access a website, the server you are accessing will send back the headers along with the HTML and anything else required to load the website. The browser will see the headers and abide by the rules set by them. Below is a sample of a response with some unnecessary headers removed.

HTTP/1.1 200 OK Date: Thu, 01 Aug 2019 14:29:22 GMT Server: Apache X-FRAME-OPTIONS: DENY X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Cache-Control: max-age=600 Strict-Transport-Security: max-age=31536000

If your web application is vulnerable to cross-site scripting, this control would prevent the vulnerability from affecting your users.

Figure 1: High-level XSS header flow

Below is the narrative for each flow.

• The attacker sends a malicious link to a user after identifying a cross-site scripting vulnerability on your web site. https://your-website.com/search.php?

• The user clicks the link and visits the website

• The website begins to load

• The web server responds with the headers it wants the browser to abide by

• The browser sees the X-XSS-Protection header set to block and blocks the attack

While this sounds great in theory, it does have its limitations in practice that browsers have recently begun to accept.

Shortcomings of XSS Filters

First, the control can only protect against reflected cross-site scripting, which is only one of the three cross-site scripting attacks. While reflected XSS is the more common of the three, the inability to prevent the remaining two doesn’t capture or mitigate the entire risk.

Second, the ability to evade the control has become increasingly common, which presents the owners of the web applications with a false sense of security. Google has even said that any evasions were “functional bugs” and that the underlying security issue is within the web application.

Lastly, if the control is not blocking or being bypassed, it’s causing false positives which prevents legitimate users from being able to access non-malicious scripts. In doing so, many developers have decided to disable the control entirely.

The Solution

Google is working on a new feature that will only mitigate DOM-XSS, where once again only one of the three XSS attacks will be mitigated.

Instead of relying on browsers to protect users from malicious scripts, the web application itself should not let the malicious scripts get to the users in the first place. To achieve this, you need to introduce secure coding into your SDLC, also known as Secure Software Development Life Cycle (SSDLC) that will encompass the OWASP Top 10 to prevent cross-site scripting and the other common injection attacks.

Once the SSDLC program is functional, the developed code will undergo consistent code scans through-out the life cycle which should lead to fewer insecure coding findings if third-party penetration tested before launch.

Conclusion

A SSDLC program plays an integral role in the security of your web applications, however, with the multitude of time and compliance constraints for developers, it becomes easy to neglect such a program. Developers are the key to application security, but they require penetration testing professionals to help widen their perspective on application security vulnerabilities. We see firsthand that clients who reach out to us to test their web applications walk away with an immediate benefit for their organizations: delivering code with fewer security defects.