Internet Explorer 8 offers a cross-site scripting feature. How does it work, and is it unique to IE8? Do other browsers offer built-in cross-site scripting prevention?
Cross-site scripting (XSS) vulnerabilities enable an attacker to control the relationship between a user and a website or application. This can allow the attacker to steal cookies and hijack accounts, monitor keystrokes, and perform actions on the website as if the attacker were the real user.
Many in the IT community believe XSS attacks are more theoretical than practical; believing that despite plenty of media attention, they lead to few harmful attacks. The reality though is XSS vulnerabilities are one of the most common flaws found in websites and topped the SANS Top 25 Most Dangerous Software Errors last year. Hackers mercilessly take advantage of cross-site scripting vulnerabilities and most major sites have been the victim of a successful attack at one time or another.
There are two basic types of XSS attacks: persistent and reflected. Persistent XSS is an attack that's stored on the site, in a comment or some other user-generated content, and can attack any user viewing that content. Reflected attacks have the payload stored in the HTTP request itself, GET parameters or FORM values ,for example. The injected code is sent to the vulnerable Web server, which uses it to generate its response, a search result or error message in most cases. This is sent or reflected back to the user’s browser, which then executes the code because it came from a trusted server.
To help protect users against these attacks, Microsoft introduced the Internet Explorer 8 XSS filter. Its objective is to provide defense in depth via automatic detection and prevention of reflected XSS attacks. The XSS filter operates as an IE8 component with visibility into all requests and responses flowing through the browser. When the filter discovers a possible XSS attack in a cross-site request, it blocks the malicious script from executing if it's going to be replayed in the server’s response. As you can imagine, there are various subtle scenarios that the filter must handle, as well as ensuring it doesn't introduce new attack vectors when it modifies the server's response (if it alters a response, it has to make sure the alteration itself doesn't provide an opportunity for an attacker to maliciously insert an attack).
The filter is effective even without modifying an initial request to the server or blocking an entire response. (If Internet Explorer’s Application Compatibility Logging is enabled, all XSS filter activity can be viewed using the Microsoft Application Compatibility Toolkit.) This ability, combined with efforts to ensure site compatibility isn't compromised, make vulnerabilities much more difficult to exploit; but it is not an XSS panacea. Unfortunately, a more rigorous filter would probably lead to users just turning it off and losing the protection it provides.
This was first published in September 2011