Paid Advertising
web application security lab

BlueHat Errata

Well BlueHat is officially over, although I’m still in meetings - I’ll post some details and some of the photos later. Meanwhile I’ve been meeting a lot with the security teams (as you probably would have guessed). I did end up getting quite a lot of technical meat out of them, most of which is for a later date, but two things in particular struck my interest because they were things I personally had gotten wrong over the last few months, and I wanted to correct myself before someone else did.

The first is that somewhere, at some point, someone mentioned that the bug was closed in IE7.0 that allowed webpages that did not set charsets to be framed and inherit the charset of the parent frame. Alas, it has not been fixed. Someone told me or maybe it was on a blog somewhere, perhaps. At any rate I didn’t attempt to verify for myself. So I’m pretty sure at some point I mentioned it on the forums or on the blog but anyway, it’s not fixed. Initially, as I found this out, I thought, “Whoah, that’s bad.” But as I talked with the MS guys, I realized it’s really not that bad if you take in context of the situation it has to manifest itself.

For that bug to work it has to be a site that you cannot find XSS in (otherwise why bother with this convoluted method)? So that leaves the remaining 20% or whatever percentage of sites you cannot XSS directly or whatever the real number is, 10%… whatever. Then that same site needs to omit no charset. That leaves a pretty damned small number right there. Then you have to also find some way to inject some text on the page that would otherwise be blocked if it were traditional XSS. So yeah, while this does have some potential for exploitation it’s pretty damned statistically insignificant from what I can tell in how many additional sites it would allow you to XSS. Still, it needs to be fixed and the MS guys are indeed fixing it, but I’m not going to run screaming through the streets over that one.

The second mistake I’m sure I’ve made at some point was surrounding HTTPOnly. I’ve heard from a lot of different people that HTTPOnly cookies can be read by XMLHTTPRequest. Stupidly, I told MS that without blinking an eye having never verified it for myself. Thankfully they went and verified, and whoops, I was mis-informed. After they nicely told me I was on crack I went and figured out what was going on. That is true in Firefox, but Firefox doesn’t support HTTPOnly yet anyway, so who cares? IE quietly and nicely ignores those headers as it should. So while I’m sure other people blindly believe HTTPOnly is broken in IE7.0, I’m pretty certain unless you can somehow trigger the TRACE method again inside XMLHTTPRequest, it’s not broken by what we know today - I won’t speak for tomorrow, though. :)

I feel better now that I’ve set the story straight on that. Anyway, this isn’t the only thing I got out of the conference - don’t worry, but it was probably the most urgent thing for me to take care of talking about.

3 Responses to “BlueHat Errata”

  1. RSnake Says:

    Even minutes after I posted this I found a real world example of the iframe charset parent inheritance problem in IE7.0 posted on the forums for anyone curious to see the issue in the wild:,11051#msg-11396

  2. Wladimir Palant Says:

    The thing is - usually you fight XSS by encoding entities. But with UTF-7 you don’t need to use any characters that will be encoded, nobody thinks twice before letting + and - pass through unchanged. So: no, I don’t think the charset inheritance issue is a minor one. It will make lots of sites that are properly encoding entities vulnerable only because they didn’t bother to set a charset.

    As to reading out cookies with XMLHttpRequest in Firefox - you mean that Set-Cookie response header can be read? Since HTTPOnly is now implemented this is in fact a bug. I couldn’t find an existing bug on this so I filed one:

  3. XJ Says:

    Set-Cookie response header (which contains HTTPOnly cookies) can also be read in IE6, IE7 not tested.