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.
Dig Deeper on Application attacks (buffer overflows, cross-site scripting)
Related Q&A from Michael Cobb
Can two-factor authentication be applied to a mobile device that's used as a 2FA factor? Michael Cobb explores the different knowledge factors and ...continue reading
Running a private certificate authority can pose significant risks and challenges to meet baseline requirements. Michael Cobb explores what ...continue reading
A recently discovered Android app permissions flaw can expose users to attacks. Michael Cobb explains what the risks are and how Android O security ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.