Paid Advertising
web application security lab

XSSFilter Released

You may have already seen the news about the new XSSFilter in IE8.0 but I wanted to echo it here as well, because it’s a pretty major new release. It does a great job of preventing most of the reflected XSS attacks out there for default users of the browser when it hits production. Very cool stuff. By the way, the second link above also has a sneak peek as to another security feature in IE8.0 if you look closely.

Think of XSSFilter like noscript in Firefox, but without the turning off JS portion of the functionality, and unlike noscript, it’s default in the browser, so it will impact a lot more people. David Ross (the guy who came up with the term Cross Site Scripting in the first place, btw) wrote this tool to start tackling a problem he’s been thinking about for 8 or more years since that paper was first authored. It’s not perfect, don’t get me wrong, but it’s a huge leap forward in the right direction, and I was hugely honored to be a part of it, since I think it will have a great positive impact on consumer security while us security knuckle draggers figure out a way to get websites to start securing themselves.

Next on my wish list? Content restrictions!

8 Responses to “XSSFilter Released”

  1. maluc Says:

    I’m gunna assume the second new feature is the domain highlighting .. which is a pretty novel idea for helping the common man discern between genuine sites and phishing sites. I certainly think it’s more useful than the EV certs (green addy bar), that small businesses can’t afford.

    But even that, i think will have very little effect on phisher’s pocket books. Sure it may hurt them when trying to send them to .. but they’ll just stick with the other tactic of (which is currently available fyi)

    The XSSFilter is definitely a step in the right direction, and hopefully syncs up with how firefox is implementing it - so i can go back to pentesting with firefox..

  2. Wladimir Palant Says:

    Well, that’s certainly a far more sane approach than NoScript’s “let’s break the web”. Question is whether they can really recognize enough attack vectors reliably to make a difference. If replacing <script> by <body onload=”"> or obfuscating the attack slightly with ignored characters, fake attributes and the like is enough to work around the filter - that won’t be worth anything. IE isn’t released often enough to keep adjusting filters to current threats, not even IE’s security patches are. The bad guys will simply switch to slightly more complicated attack vectors.

    I would really like to play around with this approach in a Firefox extension - now if I could only find time…

  3. Mark Says:

    All this comes down to the client’s browser. As long as a browser has its default settings for active scripting/jscripts enabled, the visitor runs the risk of any and every kind of xss. And what the real web-server does to filter input is irrelevant. An attacker can replace, inject or otherwise manipulate every html element from the response anyway he wants and present it to the victim’s browser, because the browser runs client-side scripts.

    The whole idea of the noscript plugin or any other plugin like the aforementioned xssfilter is to provide to the user a default/easy way to control scripting (instead of going tools options->security etc., ticking a bunch of boxes). When such a filter exists on the firewall, antivirus, browser etc., in general on the client-side should be sufficient to eliminate xss attacks.

  4. Giorgio Maone Says:

    @Wladimir Palant:
    would you care to explain how IE8’s approach is any better or even different than NoScript’s, other than being less sensitive by design?
    OK, these filters as said to check if the supposed payload is actually echoed back in the rendered page, and this may slightly reduce false positives on those sites which actually accept script tags and echo them back correctly escaped; but you’ll admit this is a very edgy case. On the other hand, they’re apparently open to an endless flood of false negatives.
    And yes, as far as we can see, they don’t even try to detect attribute-based and string literal breaking script injections, much like ASP.NET filters…

  5. Wladimir Palant Says:

    @Giorgio Maone:

    1) XSSFilter is unlikely to be triggered by valid requests, it doesn’t get triggered by single characters.
    2) They check whether the site is actually vulnerable to reflective XSS and echoes back the attack payload.
    3) They don’t block the request altogether but rather do the escaping themselves.
    4) They offer a way for the owner of the site (not the user who doesn’t have the knowledge) to allow suspiciously looking requests.
    5) XSSFilter doesn’t come with an extensive (and unjustified) whitelist.

    Yes, this solves only one part of the problem, and main question is whether they will be able to make successful XSS attacks sufficiently hard. On the other hand, an approach that breaks half of the Internet has no chance of widespread adoption. So while NoScript only solves the problem for the most paranoid users, XSSFilter aims at solving a part of it for everybody - and thus at eliminating that part.

  6. Giorgio Maone Says:

    @Wladimir Palant:

    1) NoScript does not trigger on single characters either. It triggers on payloads containing HTML fragments or valid Javascript, checked in real time against the Mozilla HTML parser and/or the SpiderMonkey JS interpreter, under multiple encoding variations (this is called the InjectionChecker engine)

    2) I’m the one who pointed that difference, and the slim false positive reduction is counter-balanced by a flood of false negatives like this one:

    3) You know that NoScript has been the first implementing a non-blocking approach, escaping instead of preventing the load. When I designed this feature, I remember I got criticized because “if requests are deemed bad, they need to be blocked outright”, but I believed and still believe interrupting users equals pushing them to bypass security (UAC anyone?). I’ve no problem in saying this approach and the UI are a rip-off of NoScript concepts.

    4) NoScript does not and will never allow overriding by the site. That’s a job for Site Security Policy. NoScript is about putting users in control, and SSP is a nice complement on the server side.

    5) NoScript does not come with “an extensive XSS whitelist” either. The only XSS exceptions are Google Search, Yahoo! Search and Wikipedia, for mere historical reasons. NoScript’s InjectionChecker engine is mature enough to discriminate even non-executable JSON from executable JavaScript, therefore the old default exceptions will be probably removed in a future release.

    I can see you’re completely misinformed about NoScript’s Anti-XSS Protection, probably basing your judgment on the very first prototypes I showed you more than one year ago as a friendly preview to learn from your opinions, and you harshly dismissed as a thing which could never work. For instance, I’m under the impression you still believe that only requests from untrusted to trusted sites are checked, while *every* cross-site request is scanned throught the InjectionChecker engine and escaped as needed, no matter if they come from a whitelisted site.

    Surprised? Please update your views.

  7. Kyo Says:

    What about the other direction?

    Couldn’t you block out certain HTML on websites by making it APPEAR like XSS by putting the exact same string in the URL?

    Take ebay, for example. Last time I checked, it allowed some javascript and blocked a fair share through javascript itself. What if I now manipulate an URL so that it looks like ebays javascript filter is XSS, wouldn’t that do the opposite of good and make the page vulnerable?

  8. x-tense Says:

    New details are avaible :