IE8 Security Part IV: The XSS Filter

a-foton » IE8 Security Part IV: The XSS Filter

a-foton » IE8 Security Part IV: The XSS Filter — Wed, 02 Jul 2008 19:10:43 GMT

PingBack from http://blog.a-foton.ru/2008/07/ie8-security-part-iv-the-xss-filter/

Internet Explorer 8 security features

SuperSite Blog — Wed, 02 Jul 2008 19:31:22 GMT

I just posted an article about Internet Explorer 8 security features . This is based on a recent briefing

IE8 goes on the offensive against XSS!

random dross — Wed, 02 Jul 2008 19:33:50 GMT

IE has announced the new XSS Filter feature which will debut in IE8 Beta 2! Stay tuned to my blog in

re: IE8 Security Part IV: The XSS Filter

Kwispel — Wed, 02 Jul 2008 20:31:47 GMT

"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.

Der sicherste Internet Explorer aller Zeiten

TheUndeadable entwickelt — Wed, 02 Jul 2008 23:34:32 GMT

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-Filt

Der sicherste Internet Explorer aller Zeiten

TheUndeadable entwickelt — Wed, 02 Jul 2008 23:35:19 GMT

re: IE8 Security Part IV: The XSS Filter

Bill — Wed, 02 Jul 2008 23:44:20 GMT

@Kwispel - agreed.

The existing info bar is confusing enough that users already ignore it.

"To help protect your security, Internet Explorer has restricted this webpage from running scripts or ActiveX controls that could access your computer. Click here for options..."

It is very frustrating because of:

1.) Most users have no idea what a "control" is.

2.) Most users have only heard of "ActiveX" in reference to a bug/virus outbreak (thus all ActiveX is considered bad.

3.) No where is "JavaScript" mentioned, which is the only term they would understand... and one which most users understand is safe. (we're talking JavaScript, not JScript here)

As for the new bar text, something like this would be much easier.

"Internet Explorer has removed some potentially unsafe content from this page. - Click here for more information"

re: IE8 Security Part IV: The XSS Filter

EricLaw [MSFT] — Thu, 03 Jul 2008 00:41:47 GMT

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.

re: IE8 Security Part IV: The XSS Filter

Tino Zijdel — Thu, 03 Jul 2008 02:04:26 GMT

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...

Internet Explorer is evolving

SNACKFIN.COM — Thu, 03 Jul 2008 04:40:23 GMT

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...

False Positives

Darko — Thu, 03 Jul 2008 08:20:50 GMT

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?

re: IE8 Security Part IV: The XSS Filter

考试中国 — Thu, 03 Jul 2008 09:56:56 GMT

“用户没有提出的问题他们无法回答”

我不认为用户会明白什么是“即修改此页中，以防止potenial跨网站指令码攻击”的手段。

re: IE8 Security Part IV: The XSS Filter

kswchina — Thu, 03 Jul 2008 09:59:06 GMT

“用户没有提出的问题他们无法回答”

我不认为用户会明白什么是“即修改此页中，以防止potenial跨网站指令码攻击”的手段。

re: IE8 Security Part IV: The XSS Filter

.mario — Thu, 03 Jul 2008 10:38:44 GMT

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 ;)

Missing Credits :)

Giorgio Maone — Thu, 03 Jul 2008 11:05:00 GMT

The sincerest form of flattery? http://noscript.net/features#xss

Internet Explorer 8 - Security

Timeless Journeys — Thu, 03 Jul 2008 13:07:48 GMT

Internet Explorer 8 - Security

re: IE8 Security Part IV: The XSS Filter

rvdh — Thu, 03 Jul 2008 13:44:58 GMT

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.

re: IE8 Security Part IV: The XSS Filter

Ryan — Thu, 03 Jul 2008 16:13:02 GMT

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?

re: IE8 Security Part IV: The XSS Filter

Joshbw — Thu, 03 Jul 2008 16:53:14 GMT

"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.

re: IE8 Security Part IV: The XSS Filter

Jeria — Thu, 03 Jul 2008 17:48:24 GMT

http://blogs.zdnet.com/security/?p=1421

re: IE8 Security Part IV: The XSS Filter

EricLaw [MSFT] — Thu, 03 Jul 2008 19:12:54 GMT

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.

re: IE8 Security Part IV: The XSS Filter

Mike — Thu, 03 Jul 2008 20:01:57 GMT

"I suspect the false positives will predominantly be on poorly written websites that ARE vulnerable"

You "suspect".. I can see why IE has turned out to be such a poor software, when decisions that may affect about a billion webpages are made on such well founded grounds.

This kind of arrogance ususally comes back and bites you in the ass.

re: IE8 Security Part IV: The XSS Filter

Tino Zijdel — Fri, 04 Jul 2008 04:12:30 GMT

@Eric: Thanks for the explanation, although I doubt that my webbrowser of choice has such a "Report broken website" feature ;)

My fear is based on actual experience with tools by anti-virus vendors which try to do the same: we have been listed as an 'untrusted site' because some mallware-propagating site was 'only' 3 clicks removed from some link in our content, parts of our javascripts have been blocked because it contained the phrase 'ads' and recently we have seen a large number of bogus requests on our site because some anti-virus vendor is prefetching links from Google search-results with a certain depth, but completely disregards <base href>...

That's why I'm sceptable to any of these efforts because it seems that as a site-owner you are declared 'guilty' unless you can prove your own innocence, and it sometimes takes a lot of time before you're being rectified...

re: IE8 Security Part IV: The XSS Filter

rvdh — Sun, 06 Jul 2008 15:18:26 GMT

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.

re: IE8 Security Part IV: The XSS Filter

rvdh — Sun, 06 Jul 2008 15:21:52 GMT

BTW: I am interested in 'legitimate' features that will do this:

scheme://host/"><script>|<iframe>|<tag onload="">

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.

re: IE8 Security Part IV: The XSS Filter

Fallen — Mon, 07 Jul 2008 16:06:58 GMT

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.

re: IE8 Security Part IV: The XSS Filter

Ted — Tue, 08 Jul 2008 00:59:23 GMT

Mike:<<I can see why IE has turned out to be such a poor software>>

don't be such a dope,,, anyone that claims to speak for ALL of the billions of pages on the Internet is full of it.. at least he's honest enough to admit that he's making an educated guess!

re: IE8 Security Part IV: The XSS Filter

lucasl — Wed, 09 Jul 2008 01:36:49 GMT

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-.

re: IE8 Security Part IV: The XSS Filter

geboortekaartjes — Wed, 09 Jul 2008 19:54:39 GMT

I agree Ted, the web is way to big to give a good estimate!

MSDN FLASH IRELAND - INTERNATIONAL RESOURCES - 14 July 2008

Microsoft Ireland Blog — Thu, 31 Jul 2008 05:54:56 GMT

a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}

IE 8 XSS Filter Architecture / Implementation

Ruud de Jonge — Thu, 21 Aug 2008 11:34:04 GMT

http://blogs.technet.com/swi/archive/2008/08/19/ie-8-xss-filter-architecture-implementation.aspx Recently

Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content

IEBlog — Mon, 25 Aug 2008 22:00:59 GMT

Previous posts have covered trustworthy principles in general and some product specifics as well. Privacy

Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content

New Zealand IE8 Taskforce — Tue, 26 Aug 2008 01:52:00 GMT

Previous posts on the IE Blog have covered trustworthy principles in general and some product specifics

SDL and the XSS Filter

The Security Development Lifecycle — Wed, 27 Aug 2008 18:44:57 GMT

Steve Lipner here. When the Internet Explorer team posted the announcement about the XSS Filter feature

Internet Explorer 8 Beta 2 Now Available

IEBlog — Wed, 27 Aug 2008 22:14:29 GMT

We’re excited to release IE8 Beta 2 today for public download. You can find it at http://www.microsoft.com/ie8

Consumers Begin Using Internet Explorer 8 Beta 2

US ISV Developer Evangelism Team — Thu, 28 Aug 2008 20:17:15 GMT

The next beta for Internet Explorer has been released for broad distribution to the public, according

IE8 Security Part VI: Beta 2 Update

IEBlog — Wed, 03 Sep 2008 07:48:25 GMT

Now that Beta 2 has released, I want to provide a short update on some of the smaller security changes

Statistical Validation of the IE8 XSS Filter

IEBlog — Mon, 29 Sep 2008 20:53:03 GMT

Greetings, I’m Russ McRee of Microsoft’s Online Services Security & Compliance Incident Management

Statistical Validation of the IE8 XSS Filter

New Zealand IE8 Taskforce — Mon, 06 Oct 2008 00:26:48 GMT

Hi All, There’s an unfortunate misconception surrounding cross-site scripting (XSS) attacks that result

Безопасность IE8: изменения в Beta 2

Блог команды разработчиков Internet Explorer 8 — Mon, 20 Oct 2008 13:26:02 GMT

Теперь, когда состоялся выпуск версии Beta 2, хотелось бы рассказать вам о тех изменениях в системе безопасности

Статистическое подтверждение XSS-фильтра IE8

Блог команды разработчиков Internet Explorer 8 — Mon, 20 Oct 2008 16:13:35 GMT

Приветствую, меня зовут Русс МакРии (Russ McRee) и я являюсь сотрудником команды Online Services Security

Статистическое подтверждение XSS-фильтра IE8

Блог команды разработчиков Internet Explorer 8 — Mon, 20 Oct 2008 16:15:55 GMT

Приветствую, меня зовут Русс МакРии (Russ McRee) и я являюсь сотрудником команды Online Services Security

Trustworthy Browsing with IE8: Summary

IEBlog — Tue, 02 Dec 2008 02:36:14 GMT

Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

IE8 보안 4부 : XSS 필터

IE8 팀 블로그 — Tue, 17 Mar 2009 11:51:07 GMT

    안녕하세요, 저는 David Ross라고 합니다. SWI 팀의 보안 소프트웨어 엔지니어죠. SWI 팀이 인터넷 익스플로러 팀과 함께 작업한 결과를 IE 블로그에

Internet Explorer 8 Final Available Now

IEBlog — Thu, 19 Mar 2009 19:35:30 GMT

Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what

Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content

Блог команды разработчиков Internet Explorer 8 — Sun, 29 Mar 2009 18:28:50 GMT

IE8 и блокировка стороннего контента В прошлых статьях мы уже говорили о принципах надежности в общем

IE8 и блокировка стороннего контента

Блог команды разработчиков Internet Explorer 8 — Sun, 29 Mar 2009 18:30:23 GMT

В прошлых статьях мы уже говорили о принципах надежности в общем и о некоторых особенностях браузера

IE8 и блокировка стороннего контента

Блог команды разработчиков Internet Explorer 8 — Sun, 29 Mar 2009 18:32:22 GMT

В прошлых статьях мы уже говорили о принципах надежности в общем и о некоторых особенностях браузера

End to End Trust and Windows 7

Windows Security Blog — Tue, 21 Apr 2009 20:51:43 GMT

I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust: A Collaborative