Update Jul 29 2010

This "feature", eventually publicized by Sirdardckcat and Thornmaker, allowed Microsoft to win the BlackHat 2010 Pwnie award for the "Most Epic FAIL":)


Internet Explorer 8's famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS "protection" is helping XSS attackers, oh the irony.

Well, this is not exactly news among security researchers, but those aware of the details (including Microsoft of course, Eduardo "Sirdarckcat" Vela and myself) have kept a low profile so far. Check, for instance, slide #17 in my OWASP presentation (alternate link), given two weeks ago.

However, after Microsoft left it unfixed for many months, someone apparently decided to whisper this dirty little secret in Dan Goodin (The Register)'s ear.

To Microsoft's credit, this problem has no quick fix: in fact, it's way worse than a simple implementation bug. Its root is a flawed design choice: when a potential XSS attack is detected, IE 8 modifies the response (the content of the target page) in order to neuter the malicious code. This is, incidentally, the only significant departure from NoScript's approach, which modifies the request (the data sent by the client) instead, and is therefore immune.

Anyway, here's the juice: IE 8's response-changing mechanism can be easily exploited to turn a normally innocuous fragment of the victim page into a XSS injection. The attacker just needs a certain degree of control on the content of the web site to be injected: social networks, forums, wikis and even Google Apps are good prey. To be fair, Google Apps are not vulnerable anymore, since Google's properties wisely choose to deploy the

X-XSS-Protection: 0

header, which is the "safety switch" disabling IE 8's XSS protection.

So, web site owners' dilemma is, opt out or not opt out?
For browser users, there should be no dilemma at all ;-)

17 Responses to “IE's XSS Filter Creates XSS Vulnerabilities”

  1. #1 Twitter Trackbacks for hackademix.net » IE's XSS Filter Creates XSS Vulnerabilities [hackademix.net] on Topsy.com says:

    [...] hackademix.net » IE's XSS Filter Creates XSS Vulnerabilities hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities – view page – cached Internet Explorer 8’s famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS “protection” is helping XSS... Read moreInternet Explorer 8’s famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS “protection” is helping XSS attackers, oh the irony. Read less [...]

  2. #2 GµårÐïåñ says:

    Thanks for sharing Giorgio, it figures that the cure would be worse than the disease.

  3. #3 Tom T. says:

    NoScript modifies the data sent by the client, which are within the user's control.
    IE 8 modifies the target page, whose overall contents are outside of the user's control.

    "This is, incidentally, the only significant departure from NoScript’s approach..."

    The only plausible explanation for that foolish choice is that it would be embarrassing to Microsoft to appear to be copying NoScript.

    It seems that this result would be even more embarrassing. Microsoft, swallow your pride, adopt the NoScript approach, or just ask Giorgio Maone how to do it.

  4. #4 Bill says:

    IE8's protected mode in Windows 7 makes it the most secure browser on earth.

  5. #5 sirdarckcat says:

    wow.. I'm glad this didn't attracted so much attention.. after reading the comments in theregister it appears that everything is still ok..

    It's still a big shame for the 2 guys that leaked this issue.. being that I only told a few people I trust + Microsoft.. + Google..

    I was planning to make a blogpost telling people they shouldn't panic and disable all filters just because google did it.. since google is a special case because of the way google services and infrastructure works.

    Anyway,
    @Tom T.
    the IE8 xss filter prototype pre-dates noscript's filters..

    Greetings!!

  6. #6 Giorgio says:

    @sirdarckcat:
    Yes, even though Dan Goodin's article is well written and its title alone tells the whole story, doesn't look like many people actually understood what's going on.

    the IE8 xss filter prototype pre-dates noscript’s filters

    Well, I may claim that my private prototype of a XSS filter for Netscape (written in 1996) predates even IE 4, but since I kept it secret and closed source I'd have as much credibility as... Microsoft ;-)

  7. #7 Tom T. says:

    @ sirdarckcat:

    "the IE8 xss filter prototype pre-dates noscript’s filters.."

    Thank you for the timeline information.

    Still, it seems intuitively that providing a user-controlled solution is a more logical and safer approach than requiring the cooperation of web site admins and designers, the majority of whom seem to have little awareness of security issues. Plus, the average user cannot determine which sites have implemented which safety features.

    ¡Salud, dinero, y amor!

    @ Giorgio:

    "Well, I may claim that my private prototype of a XSS filter for Netscape (written in 1996) predates even IE 4, but since I kept it secret and closed source I’d have as much credibility as… Microsoft ;-)"

    LOL!

    @ Bill Gates:

    "IE8’s protected mode in Windows 7 makes it the most secure browser on earth."

    http://msdn.microsoft.com/en-us/library/cc288472(VS.85).aspx#activex

    "Internet Explorer 8 offers greater control over your Microsoft ActiveX installation and debugging.

    * Per-site ActiveX — Nearly half of all ActiveX controls meant to run on only one site do not use any form of site locking technology. This means that many controls are not secure by default and could be misused by malicious Web sites. To prevent this in Internet Explorer 8, users can decide whether to allow ActiveX controls to run on a site-by-site basis. For more information, see Per-Site ActiveX Controls.
    * Non-administrator installation — Standard users (those without administrator privileges) can install ActiveX controls to their user profiles without a UAC prompt or administrator involvement of any kind. In the event that a user does install a malicious ActiveX control, only the user profile is affected; the system itself is not compromised. For more information, see Non-Admin ActiveX Controls. "

    So, after admitting what everyone else already knows -- that ActiveX is a dangerous technology -- the "improvement" is that users may choose to allow it on a per-site basis, something that could have been done through the IE Zone settings at least as far back as IE 5. But how is the average user to know whether any given AX control is safe, especially since MS itself does not, given the number of buffer-overflow and other vulns discovered in AX controls for the past decade, and still being discovered as of the last Patch Tuesday? MS KB 973525

    The other "improvement": Now, a standard user who installs a malicious AX is pwned only on his/her own profile.

    Any browser, including Firefox, that does not support ActiveX is inherently safer than IE.

    "...most secure browser on earth"? Strange definition of "secure", Sir.

  8. #8 sirdarckcat says:

    Hey could you upload your ppt? the owasp site fails..

  9. #9 Giorgio says:

    @sirdarckcat:
    http://maone.net/downloads/OWASP-Italy_Day_IV_Maone.pdf

  10. #10 sirdarckcat says:

    #9 @giorgio
    thankz! thats a great ppt!!

    regarding slide 16: user can disable the filter..

    Anyway, mmm maybe you mean "unsafe reload" so then you are right.. that's not possible..

    I think webkit's approach compared to IE's is better (regarding compatibility) but IE is safer (actually, is the one with less bypasses so far.. evendo they did created security issues with the response rewriting approach..).. but NoScript request modification is known to either:
    1.- break things (POST unsafe reloads for instance)
    2.- hard to spot bugs (I wasnt used to check the error console before)

    I would recommend you to allow the server to disable NoScript's filter.. anyway, I dont have any good idea on how to do it.. =/

    Said that.. great ppt again!! :)

    Greetings!!

  11. #11 Giorgio says:

    @sirdarckcat:

    Thanks for your comment.

    Yes, I was referring to "unsafe reload".

    break things (POST unsafe reloads for instance)

    Nope, a POST unsafe reload doesn't break anything because the filtered request had been turned in a data-less GET and therefore did not modify webapp status.

  12. #12 sirdarckcat says:

    > Nope, a POST unsafe reload doesn’t break anything because the filtered request had been turned in a data-less GET and therefore did not modify webapp status.

    I was refering to one time.. where the POST was stripped but the GET args were left, so it trigers an error (with the GET args) since there's no POST data.. then if you do unsafe reload, it trigers an error since the nonce sent via GET was used before.

    anyway, I only found that specific case on some openid service I was pentesting.. (against logic flaw errors, nothing to do with xss).. but well..

    Greetz!

  13. #13 Mr. Foo says:

    XSS-Schutz des IE8 exploitbar

    Der XSS-Schutz des IE8 bröckelt.Der neueingeführte Cross-Site-Scripting Schutz des Internet Explorer 8 lässt sich anscheinend aushebeln.
    Gorgio (der Entwickler von NoScript) berichtet in einem Blogeintrag darüber.
    Konkret liegt das Problem in der...

  14. #14 وسيلة الحماية من هجمات XSS على Internet Explorer 8 غير آمنة | المجلة التقنية says:

    [...] http://hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities/ Share and Enjoy: [...]

  15. #15 Tech Thursday – Python and YQL, new Google layout, Quake in Flash and LOLSQL | Techno Portal says:

    [...] Ironically a bug in Internet Explorer’s XSS filter allows to inject code into web sites. [...]

  16. #16 Tom T. says:

    @ #14: My Arabic is a little more rusty than my German, but it looks like the headline is:

    Technical magazine: Non-secure IE 8 across XSS as a means of protection against attacks

    From the article:

    "NoScript is in disagreement with the add-on in IE8.
    It analyses answers server and not requests for users, which could be the attackers of manipulation of answers server and injection certain codes for its implementation, Giorgio Maone says.

    "And who did not disclose the details of the matter is that the whole matter is based on an error in the basic design, which should be reconsidered in the design, Maone adds."

    Pretty bad translation -- I know people who could do better -- but the bottom line comes out the same in any language. Looks like the whole world knows the story. :-)

  17. #17 Jess says:

    As for me, I am using this tool for preventing XSS disasters:
    http://xss-scanner.com

Bad Behavior has blocked 2430 access attempts in the last 7 days.