IE8 Security Part IV: The XSS Filter
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:
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.
While many great tools exist for developers to mitigate XSS in their sites / applications, these tools do not satisfy the need for average users to protect themselves from XSS attacks as they browse the web.
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.
And of course in addition to all of this we need to effectively counter all the XSS attack vectors not already addressed by other XSS-Focused Attack Surface Reduction measures.
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 “><script>… 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
Comments
Anonymous
July 02, 2008
PingBack from http://blog.a-foton.ru/2008/07/ie8-security-part-iv-the-xss-filter/Anonymous
July 02, 2008
I just posted an article about Internet Explorer 8 security features . This is based on a recent briefingAnonymous
July 02, 2008
IE has announced the new XSS Filter feature which will debut in IE8 Beta 2! Stay tuned to my blog inAnonymous
July 02, 2008
"Users are not presented with questions they are unable to answer" I don't think the users will understand what "IE modified this page to prevent a potenial cross-site scripting attack" means.Anonymous
July 02, 2008
Der IE 8 wird der sicherste Internet Explorer aller Zeiten! Ungelogen! IE8 Security Part V- Comprehensive Protection: XSS-Protection, XDomainRequest, HTML/JSON Sanitization, MIME-Handling, DEP, File Upload IE8 Security Part IV- The XSS Filter: XSS-FiltAnonymous
July 02, 2008
Der IE 8 wird der sicherste Internet Explorer aller Zeiten! Ungelogen! IE8 Security Part V- Comprehensive Protection: XSS-Protection, XDomainRequest, HTML/JSON Sanitization, MIME-Handling, DEP, File Upload IE8 Security Part IV- The XSS Filter: XSS-FiltAnonymous
July 02, 2008
The comment has been removedAnonymous
July 02, 2008
Please keep in mind that this information bar isn't a ~prompt~ that asks the user to make a security decision, this is a ~notification~ that a security protection was activated. The notice is shown to help IT Admins and Web Developers troubleshoot any XSS Filter-related page modification. It's quite unlikely that any user will see this information bar in the course of normal browsing.Anonymous
July 02, 2008
I have only two questions:
- where can we (website owners) report any false positives?
- how will MS deal with those reports? Suggesting to set a proprietary HTTP header may seem to be a nice opt-out but may leave your site vulnerable to other real XSS exploits that you may want to see blocked by IE. Besides, if every software vendor should choose to suggest this kind of opt-out we finally end up sending kilobytes of HTTP headers just to suit every software vendor on the block - many of which are known to make mistakes with their 'security features'. My fear is that with every 'possible attack vector' Microsoft wants to mitigate the number of false positives will rise. Hopefully the implementation will be somewhat smarter than f.i. the 'bad content' filter used for MSN...
Anonymous
July 02, 2008
First a recent warning from McAfee -- if you're still using IE 6, it's time to upgrade. From SecurityNewsPortal.com: Anyone using Internet Explorer 6 should upgrade to the latest version of the browser, IE7, to avoid security risks. A researcher...Anonymous
July 02, 2008
What is the IE team doing to ensure the minimum amount of false positives? Also will this degrade performance on JS heavy sites like Gmail or Facebook?Anonymous
July 02, 2008
“用户没有提出的问题他们无法回答” 我不认为用户会明白什么是“即修改此页中，以防止potenial跨网站指令码攻击”的手段。Anonymous
July 02, 2008
“用户没有提出的问题他们无法回答” 我不认为用户会明白什么是“即修改此页中，以防止potenial跨网站指令码攻击”的手段。Anonymous
July 02, 2008
From experience I can say that it is going to be a matter of minutes until the filter is broken/circumvented. I can't await the release to start tinkering with this feature ;)Anonymous
July 02, 2008
The sincerest form of flattery? http://noscript.net/features#xssAnonymous
July 02, 2008
Internet Explorer 8 - SecurityAnonymous
July 02, 2008
Why the choice for modifying a page, instead of blocking the request all together? it only increases the chance of circumvention. IMHO regarding reflected XSS, all URI's and/or querystrings containing HTML should be blocked because I am not aware of such legitimate use whatsoever in any application.Anonymous
July 03, 2008
Maybe I'm missing something obvious, but if web developers can disable this filtering by using "X-XSS-Protection: 0", what's stopping the bad guys from doing the same?Anonymous
July 03, 2008
"Maybe I'm missing something obvious, but if web developers can disable this filtering by using "X-XSS-Protection: 0", what's stopping the bad guys from doing the same?" This is inserted as a header, which is MUCH more difficult for a third party to insert into (your website has done something exceptionally bad if they can do so). XSS is trivial, header injection reflected back to the client, not so much. As for the false positives, I suspect the false positives will predominantly be on poorly written websites that ARE vulnerable. If parameters in the URL are being echoed back in the html without entity encoding the website is poorly designed and XSS does exist, even if a specific URL actually functions the way the developer intended.Anonymous
July 03, 2008
http://blogs.zdnet.com/security/?p=1421Anonymous
July 03, 2008
Ryan: Yes, JoshBw is correct. Header injection attacks are MUCH less common than script-injection attacks via XSS, by orders of magnitude at least. If a bad guy is able to inject new custom headers in your browser, XSS is the least of your worries as chances are good that he could entirely replace the page. Joshbw is also correct to note that most false positives aren't false positives as all, but actually evidence of potential for future exploit. rvdh: Compatibility is key. It's somewhat non-intuitive, but think about it: your car is fast because it has brakes (because then you can slow down when you need to). In the same way, the investment we made in compatibility lets us have very aggressive heuristics, because even in the event of a false match, chances are good that the resulting page will not be broken. Hence, we are able to catch more XSS attacks. There are many legitimate uses of URLs that contain potential scripting constructs. In the extreme example, consider a site that allows the user to share sample Javascript with other users. If we were to block all outbound script, then such a site would be impossible to build, even though the site (if properly coded) had no XSS vulnerabilities. So, as you can see, our ability to block the attacks only (without harming non-attack sites) means that we can keep the XSS filter enabled and aggressive. @Darko: There's no meaningful performance degradation for the sites you mention, as the filter only fires in the event of cross-domain navigations, and only then in very rare cases. As described previously, the feature was designed around compatibility, because minimizing false positives is key to ensuring that users are able to benefit from the protections of this feature. @Tino: You can report false positives to us through the "Report broken website" tool or even email me directly (ericlaw at microsoft) although, as noted, most false-positives are actually proof of latent exploitability. It's possible to build a contrived site that deliberately fires false-positives, but it's easy to avoid these without actually turning the feature off via the header.Anonymous
July 03, 2008
The comment has been removedAnonymous
July 03, 2008
The comment has been removedAnonymous
July 06, 2008
Well I do think it's a very good idea, if a developer uses MSIE to test his site, he immediately sees that something is broken, and probably will fix it. So, it can be very helpful to get rid of XSS all together and be an educational tool for surfers as well for developers. However I'm still for blocking the request all together instead of modifying it and raise a warning. I am not sure how it gets modified, but it could lead to other attacks as well, because re-writing Javascript never really worked quite well in filters. All filters I know about had at least one flaw concerning re-writing content that opened up new vectors.Anonymous
July 06, 2008
BTW: I am interested in 'legitimate' features that will do this: scheme://host/"><script>|<iframe>|<tag onload=""> or scheme://host/querystring?param="><script>|<iframe>|<tag onload=""> it really doesn't belong in URI's/query strings IMHO. And I have to see the first page that actually does this kind of behavior.Anonymous
July 07, 2008
I'm wondering how well this filter deals with obfuscation of code, which has been shown in the past to be one of the harder parts of getting a decent xss filter made. It's great that this has been implemented, but if the filter only goes 1-2 levels of obfuscation deep then there's probably more work to be done.Anonymous
July 07, 2008
The comment has been removedAnonymous
July 08, 2008
I can already picture this as a new strong reason/excuse for programmers not to get educated on secure programming, relying on this feature. Speaking from a security consultant standpoint, its already hard enough to explain devs why a fix is neccesary. Ie is just a -choice-.Anonymous
July 09, 2008
I agree Ted, the web is way to big to give a good estimate!Anonymous
July 30, 2008
a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}Anonymous
August 20, 2008
http://blogs.technet.com/swi/archive/2008/08/19/ie-8-xss-filter-architecture-implementation.aspx RecentlyAnonymous
August 25, 2008
Previous posts have covered trustworthy principles in general and some product specifics as well. PrivacyAnonymous
August 25, 2008
Previous posts on the IE Blog have covered trustworthy principles in general and some product specificsAnonymous
August 27, 2008
Steve Lipner here. When the Internet Explorer team posted the announcement about the XSS Filter featureAnonymous
August 27, 2008
We’re excited to release IE8 Beta 2 today for public download. You can find it at http://www.microsoft.com/ie8Anonymous
August 28, 2008
The next beta for Internet Explorer has been released for broad distribution to the public, accordingAnonymous
September 02, 2008
Now that Beta 2 has released, I want to provide a short update on some of the smaller security changesAnonymous
September 29, 2008
Greetings, I’m Russ McRee of Microsoft’s Online Services Security & Compliance Incident ManagementAnonymous
October 05, 2008
Hi All, There’s an unfortunate misconception surrounding cross-site scripting (XSS) attacks that resultAnonymous
October 19, 2008
Теперь, когда состоялся выпуск версии Beta 2, хотелось бы рассказать вам о тех изменениях в системе безопасностиAnonymous
October 20, 2008
Приветствую, меня зовут Русс МакРии (Russ McRee) и я являюсь сотрудником команды Online Services SecurityAnonymous
October 20, 2008
Приветствую, меня зовут Русс МакРии (Russ McRee) и я являюсь сотрудником команды Online Services SecurityAnonymous
December 01, 2008
Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approachedAnonymous
March 16, 2009
    안녕하세요, 저는 David Ross라고 합니다. SWI 팀의 보안 소프트웨어 엔지니어죠. SWI 팀이 인터넷 익스플로러 팀과 함께 작업한 결과를 IE 블로그에Anonymous
March 19, 2009
Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes whatAnonymous
March 29, 2009
IE8 и блокировка стороннего контента В прошлых статьях мы уже говорили о принципах надежности в общемAnonymous
March 29, 2009
В прошлых статьях мы уже говорили о принципах надежности в общем и о некоторых особенностях браузераAnonymous
March 29, 2009
В прошлых статьях мы уже говорили о принципах надежности в общем и о некоторых особенностях браузераAnonymous
April 21, 2009
I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust: A CollaborativeAnonymous
April 23, 2015
NJNJK BIF FJGGHGJHGH