Wednesday, January 06, 2010

To disable IE8's XSS Filter or not?

Since this article was published, Major IE8 flaw makes 'safe' sites unsafe, I’ve fielded a number of inquiries asking for guidance. Should they follow Google’s lead and proactively disable IE8’s XSS Filter (X-XSS-Protection: 0) until a patch is made available or leave it enabled? Without getting into any technical detail, here are my thoughts on the matter:

If your organization is REALLY concerned about XSS attacks, is VERY confident the website in question is one of the very few completely free from XSS issues (as apparently Google is), and is prepared to fix any XSS issues that surface within DAYS -- then you may consider disabling the XSS Filter to reduce any remaining attack surface until a patch arrives.

On the other hand if you are like most who have XSS, or don't know if they do or not, then leave the XSS Filter alone to do its job -- give your IE8 users a fighting chance.

10 comments:

thornmaker said...

I agree with this but have one thing to add.

If this issue starts to be exploited "in the wild" before Microsoft issues a fix, then I would temporarily disable the filters until your sites users have been given a chance to upgrade.

To my knowledge, this has not happened yet.

Jeremiah Grossman said...

@thornmaker, good point, thanks for the comment. I'd also guess that in-the-wild exploitation of this is highly unlikely given so much vanilla XSS available. :)

thornmaker said...

It's not the XSS-riddled sites that need to worry...

Stephan Wehner said...

Use a different browser?

Stephan

0kn0ck said...

I think its a good additional practice to check website for advanced auditing and web application testing.

Check

http://zeroknock.blogspot.com/2009/11/http-x-protection-headers-microsoft.html

chriscla said...

I am not familiar with the vulnerabilitiy, but this is an interesting case study.

Suppose attackers can trigger this bug to cause XSS on any site. If that's the case, and the Register article implies that it is, then attackers won't bother to find your site-specific XSS. Instead they will use their off-the-shelf Anti-AntiXSS exploit. Attackers prefer OS bugs for the same reason -- they can discover the bug, package a reliable exploit, and continually re-use it.

If Microsoft confirms an issue with the Anti-XSS protections, sites should disable it until a fix becomes available.

Jeremiah Grossman said...

@chriscla, you know that is a really good point, an aspect of risk I didn't see previously considered. You could in fact be right, given the exploit becomes generally available. Right now, my understanding is that it's not in-the-wild so to speak.

fish said...

Just do not use a browser which sucks so hard that you need to ask such questions, and if you throw some common sense in, you'll be fine.

Chris said...

This is one of those awkward "is it public or isn't it?" situations. Given the assertion that vulnerability X exists in relatively small piece of functionality Y, I know several competent researchers who could calculate X in a very short time :)

Dan B. said...

I have an ajax app that is being broken by this "feature" of IE.

I have tried setting the x-xss-protection header to 0 and verified its in place but it does not disable the stupid feature!

It breaks a request I make to a hidden iframe to generate page content.

anyone had any luck getting legit apps through this feature?