NewsBot
1
Hi, I'm David Ross, Security Software Engineer on the SWI team. I’m proud to be doing this guest post on the IE blog today to show off some of the collaborative work SWI is doing with the Internet Explorer team.
Today we are releasing some details on a new IE8 feature that makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8. Type-1 XSS flaws represent a growing portion of overall reported vulnerabilities and are increasingly being exploited “for fun and profit.”
The number of reported XSS flaws in popular web sites has skyrocketed recently – MITRE has reported that XSS vulnerabilities are now the most frequently reported class of vulnerability. More recently, sites such as XSSed.com have begun to collect and publish tens of thousands of Type-1 XSS vulnerabilities present in sites across the web.
XSS vulnerabilities enable an attacker to control the relationship between a user and a web site or web application that they trust. Cross-site scripting can enable attacks such as:
XSS Filter -- How it Works
The XSS Filter operates as an IE8 component with visibility into all requests / 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. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.
With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:
The page has been modified and the XSS attack is blocked.
In this case the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way the filter is effective without modifying an initial request to the server or blocking an entire response.
As you may imagine, there are a number of interesting and subtle scenarios that the filter must handle appropriately. Here are some examples:
Compatibility is critical. This feature was developed with the understanding that if it were to “break the web,” we could not enable the feature by default. Or if we did, people would turn it off and get no benefit. We really want to provide as much value as possible to the maximum number of users.
If Internet Explorer’s Application Compatibility Logging is enabled, all XSS Filter activity can be viewed using the Microsoft Application Compatibility Toolkit.
Web developers may wish to disable the filter for their content. They can do so by setting a HTTP header:
X-XSS-Protection: 0
Ultimately we have taken a very pragmatic approach – we choose to not to build the filter in such a way that we compromise site compatibility. Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. This is similar to the pragmatic approach taken by ASP.Net request validation, although the XSS Filter is able to be more aggressive than the ASP.Net feature.
Assuming negligible site compatibility and performance impact, the fact that our filter effectively blocks the common “>… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8. (Not to mention the IFRAME SEO Poisoning attacks we protect against as well!)
I will go into more details on how the filter works, its history, its limitations, and some lessons learned during the development process over on my blog in the coming weeks.
David Ross
Security Software Engineer
More...
Today we are releasing some details on a new IE8 feature that makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8. Type-1 XSS flaws represent a growing portion of overall reported vulnerabilities and are increasingly being exploited “for fun and profit.”
The number of reported XSS flaws in popular web sites has skyrocketed recently – MITRE has reported that XSS vulnerabilities are now the most frequently reported class of vulnerability. More recently, sites such as XSSed.com have begun to collect and publish tens of thousands of Type-1 XSS vulnerabilities present in sites across the web.
XSS vulnerabilities enable an attacker to control the relationship between a user and a web site or web application that they trust. Cross-site scripting can enable attacks such as:
- Cookie theft, including the theft of sessions cookies that can lead to account hijacking
- Monitoring keystrokes input to the victim web site / application
- Performing actions on the victim web site on behalf of the victim user. For example, an XSS attack on Windows Live Mail might enable an attacker to read and forward e-mail messages, set new calendar appointments, etc.
XSS Filter -- How it Works
The XSS Filter operates as an IE8 component with visibility into all requests / 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. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.
With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:
The page has been modified and the XSS attack is blocked.
In this case the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way the filter is effective without modifying an initial request to the server or blocking an entire response.
As you may imagine, there are a number of interesting and subtle scenarios that the filter must handle appropriately. Here are some examples:
- The filter must be effective even if the attack is adjusted to leverage artifacts of common web application frameworks. Ex: Will an attack still be detected if certain characters in a request are dropped or translated when replayed in the response?
- In performing filtering our code must not introduce new attack scenarios that would not otherwise exist. Ex: Imagine the filter can be forced to neuter a closing SCRIPT tag. In that case, untrusted content on the page might then execute as script.
Compatibility is critical. This feature was developed with the understanding that if it were to “break the web,” we could not enable the feature by default. Or if we did, people would turn it off and get no benefit. We really want to provide as much value as possible to the maximum number of users.
If Internet Explorer’s Application Compatibility Logging is enabled, all XSS Filter activity can be viewed using the Microsoft Application Compatibility Toolkit.
Web developers may wish to disable the filter for their content. They can do so by setting a HTTP header:
X-XSS-Protection: 0
Ultimately we have taken a very pragmatic approach – we choose to not to build the filter in such a way that we compromise site compatibility. Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. This is similar to the pragmatic approach taken by ASP.Net request validation, although the XSS Filter is able to be more aggressive than the ASP.Net feature.
Assuming negligible site compatibility and performance impact, the fact that our filter effectively blocks the common “>… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8. (Not to mention the IFRAME SEO Poisoning attacks we protect against as well!)
I will go into more details on how the filter works, its history, its limitations, and some lessons learned during the development process over on my blog in the coming weeks.
David Ross
Security Software Engineer
More...