Statistical Validation of the IE8 XSS Filter

Statistical Validation of the IE8 XSS Filter : EasyCoded

Statistical Validation of the IE8 XSS Filter : EasyCoded — Mon, 29 Sep 2008 21:10:40 GMT

PingBack from http://www.easycoded.com/statistical-validation-of-the-ie8-xss-filter/

re: Statistical Validation of the IE8 XSS Filter

Ben Voigt [C++ MVP] — Tue, 30 Sep 2008 00:21:27 GMT

A more important statistic, perhaps, would be the fraction of hackers with the knowledge to execute an XSS attack today who will be unable to do so with the IE8 XSS filter. This is surely far less than 70% neutralized and likely near zero.

An arms race may work against spam, where the volume of malicious content is the problem, but in the XSS domain where individual attacks can be serious, bolt-on solutions won't work. Sites have to be re-architected to protect against the attack and not rely on a browser that statistically identifies and blocks even 99% of attack vectors.

It would be worthwhile to close some fraction of vulnerabilities, so some fraction of affected websites become safe against all attack, but I doubt this filter will do so. The hackers just have to obfuscate their scripts to the point that the filter can't recognize them.

re: Statistical Validation of the IE8 XSS Filter

Ted — Tue, 30 Sep 2008 00:59:54 GMT

That's where you're wrong, Ben. This isn't a bolt-on protection; they built it into the core engine of the browser. Remember, bad guys can obfuscate their attacks all they want, but at the end of the day, the browser has to actually deobfuscate the script enough to run it.

So an attacker needs to be able to create a script which the filter/browser doesn't recognize, but which the scriptengine/browser will run. That's a lot harder than you imply.

re: Statistical Validation of the IE8 XSS Filter

Mitch 74 — Tue, 30 Sep 2008 11:33:02 GMT

@Ted: I think Ben wasn't using 'bolt-on' to say it's a quick hack, only that this solution isn't perfect: however smart it is, it's still only a workaround for badly secured sites, and may not work in all cases. If such is the case (and that seems to be Ben's concern), the solution may bring in a false sense of security, letting users become pray to attacks that bypass the workaround.

Not to say that this is a bad thing for users (overall, it's very good), but more like something that developers should be aware of.

Note to IE developers: would it be possible to add an environment variable somewhere that would allow IE to switch to 'developer mode' where all such automatic systems provide a UI notification, with the 'user unfriendly' messages still being active? It would probably help devs to know when the website they are working on would potentially get screwed up, and advanced user (the ones who may understand cryptic messages) would probably appreciate it too.

re: Statistical Validation of the IE8 XSS Filter

steve — Tue, 30 Sep 2008 21:20:25 GMT

IE7 bug (might be in IE8 too)

If a link is opened in a new tab (from a middle-click), and that link had a target="someFrameName" attribute, the new tab's window, INHERITS this name.

This breaks frames that nest in any complex way, and does not behave like any of the dozens of browsers that implemented Tabs before IE.

Scenario:

Page

+- iframe "a"

+- iframe "b"

Normal usage:

If user clicks on a link to load in frame "b". but document loading in frame "b", contains its own iframe "c".

Links in frame "c" load within itself, but check if their parent.window.name is "b"... if so, they reload "expand" into "b".

Now in IE7, if you load a link "destined" for frame "b", in a new tab... IE names that new window "b", and SETS the parent.window.name to "b" too (which is wrong, because there isn't even a parent window!!!), thus ends up in a never-ending loop, constantly reloading into itself (since there is no parent window)

There is a hack workaround - whereby the content loaded in "c", *ALSO* checks to see if (self == top) and if so, does not do the reload in the parent because it has just encountered the above IE7 bug.

Does anyone have a better (less hacky fix?) and does anyone that has access to IE8 know if this bug is still in IE?

many thanks

re: Statistical Validation of the IE8 XSS Filter

David R. — Wed, 01 Oct 2008 17:17:07 GMT

@steve I can CONFIRM that this bug is in IE8 BETA 2 also.

I think I might be able to live with the name being passed to the new tab but "non-existent" parent frame bug is VERY cumbersome.

in IE4,IE5,IE6 this worked fine:

---------------------------------------

if(window.parent && window.parent.name == 'content'){

//load in parent window

window.parent.location.href = self.location.href;

}

now in IE7/IE8 we need to modify all of our code to handle this bug.

in IE7,IE8 this extra garbage logic is needed:

---------------------------------------

if(window.parent && window.parent.name == 'content'){

var loadInParent = true;

if(isIE7() || isIE8() ){

if(top == self){

loadInParent = false;

}

if(loadInParent){

//load in parent window

window.parent.location.href = self.location.href;

}

Note: isIE7(), and isIE8() are external functions defined to work around specific IE bugs.

Can someone at [MSFT] indicate if this bug has been fixed internally or if it will be fixed in IE8 Beta 3?

Regards,

David R.

re: Statistical Validation of the IE8 XSS Filter

Anonymous — Sun, 05 Oct 2008 22:16:25 GMT

Ben, the filter could be updated, like antivirus;with your logic, both would be worthless.

Statistical Validation of the IE8 XSS Filter

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

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

re: Statistical Validation of the IE8 XSS Filter

Ben Voigt [C++ MVP] — Thu, 09 Oct 2008 01:43:07 GMT

Ted,

Pardon me for my scepticism, but classifying self-modifying executable code (whether source code or machine code for either a VM or physical CPU) is hard. Javascript is dynamic, with self-modification capabilities. If they had a perfect solution we'd not be hearing "Microsoft develops XSS Filter", we'd be hearing "Microsoft Researcher solves Halting Problem".

Yes, you can improve the filter over time, like antivirus. And yes, if its performance is reasonable, I'll be glad to use it. But no, I won't rely on it for online security just as I don't rely on antivirus for online security. It is, as stated, simply defense-in-depth. I'm not questioning its utility, I just want people to consider whether this article as an exercise in how to lie with statistics.

From the post "identifies & neuters the attack if it is replayed in the server’s response". How many blog comments are actually replayed in the server's response? Not very many, most say something about the comment will appear in a few minutes. Ditto for wiki edits. And you can't block such posts outright without impacting all blogs that discuss programming and might have Javascript snippets, all bug tracking systems that might include code snippets, all online HTML editor/validator systems, and so on.

The responsibility of preventing the server from placing tainted user-controlled content in a page it serves subsequently lies with the server. I don't want to hear banks disclaiming responsibility for XSS vulnerabilities because "We clearly recommended that you use IE8 which stops XSS attacks".

Internet Explorer 8 XSS 필터의 통계적 유효성 검사

IE8 팀 블로그 — Thu, 05 Mar 2009 09:57:59 GMT

이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의