I’m happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of “XSS Filter” with NoScript’s Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a “neutralized” form and emitting a warning as an info-bar, which doesn’t require interaction and therefore doesn’t necessarily interrupt user’s workflow. But that’s fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript’s InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:
The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. […]
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.
And there I started smiling: you realize, guys, that those listed “on sites like XSSed.com” are not “XSS vulnerabilities” which will “stop working in IE8″, but just minimal exploit test cases —
Anyway, such a feature being deployed as a built in of a popular browser, rather than as an add-on for an awesome browser, will likely keep script kiddies busy for a while, maybe taking a filter evasion crash course. I just hope it won’t give some site owners an alibi not to fix their bugs, though, putting a “This site is best viewed with IE8” badge near to their McAfee Hackersafe logo.
Final thought: echoing the news on his blog, RSnake did swiftly mention NoScript (thanks), but at the end of that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists… Do these cross-site scripting filters suppress legitimate cross-site references as well? ;)