On July 15, Google announced that the XSS Auditor module that protects Chrome users against Cross-site Scripting attacks is to be abandoned. It was found to be easy to bypass, inefficient, and causing too many false positives. A similar mechanism was previously used by Microsoft Edge (XSS filter) and removed in 2018.
XSS Auditor was introduced in 2010. It works by monitoring communication between the web browser and the web server and looking for potential XSS patterns. Since 2016, XSS Auditor completely blocked access to the page if a potential XSS attack was found. Due to a large number of false positives, the default behavior was recently changed from blocking to filtering the potentially harmful code.
Several sources are suggesting that Google is trying to replace XSS Auditor by working on the implementation of Content-Security-Policy: trusted-types. This mechanism is meant to eliminate most potential DOM XSS attacks but is not meant to protect against other types of XSS attacks. Therefore, trusted types cannot be seen as a replacement for the XSS Auditor and there will be no replacement for the client-side protection mechanism. This increases the importance of protecting against XSS attacks by finding vulnerabilities as soon as possible.
Faulty by Design
There are two basic approaches to eliminating vulnerabilities: fixing them or going around them. The first approach involves finding errors in the application code and changing them. The second one means having an intermediate agent that blocks out potential attacks based on patterns. XSS Auditor used the second method, which yet again proved to be ineffective.
The XSS Auditor in Chrome works in a way very similar to how Web Application Firewalls (WAFs) work – they also use patterns to eliminate potential attacks. WAFs are excellent for zero-day protection – they can help prevent attacks before a vulnerability is fixed. However, they must not be used on their own and cannot be perceived as a long-term solution to web security. The only certain way to protect yourself against vulnerabilities is to manage them and eliminate them as early as possible in the software development lifecycle. And to eliminate them, you first need to know that they exist – that is what business-class web vulnerability scanners are for.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/26V39NPNGNw/