Paid Advertising
web application security lab

IE8.0 US-ASCII and Other Stuff

David Ross had a good blog post a few weeks back about how IE8.0 is no longer vulnerable to the US-ASCII encoding attack. For those of you who don’t know what I’m talking about you can find an example of it on the charsets page. Looks like both of the browser manufacturers are stepping up their game a little for the next version of the browsers to hit the market.

On a side note, and something I’ve been meaning to post for a while now, I’ve found a discrepancy between IE and Firefox that I think is worth noting. Most of the time this isn’t an issue but most web-pages decode Unicode inputs, so the fact that Firefox automatically encodes every GET parameter with Unicode is not a big deal. However, if the page doesn’t do any conversions, but rather echos the data back exactly as it was seen Firefox isn’t vulnerable. However, Internet Explorer is - because it doesn’t convert " into %22 for instance.

It’s a subtle difference, and only effects certain websites, but it was big enough of an issue that I had to switch testing methods because Firefox wasn’t giving me the results I was expecting - even though I could see the vulnerability using a proxy. I don’t know what percentage of pages do this, but it will lead to a lot of false negatives in scanners that are looking for XSS injection, if they follow the RFC. Net result for me? Firefox = less good for testing and IE = less secure.

Meanwhile, not that anyone cares, but it turns out that blogging is going to make me die an unfortunate and unglamorous early death. And I always thought it was because it was going to be due to an explosion. You people totally owe me. I expect payment in the afterlife.

12 Responses to “IE8.0 US-ASCII and Other Stuff”

  1. pdp Says:

    I don’t know about you but I am using a bash script to write my blog posts :)

    apart from the joke, most bloggers are sploggers really :) they just duplicate content. and there are plenty of programmable tools that you can use for aggregating and paraphrasing the content so that it doesn’t look like a total splog. heck, even word has a paraphrasing tool built in by default. :)

    hacking is a survival trick!

  2. Justin Says:

    There is a preference which effects query string encoding in Firefox:

  3. Ronald van den Heetkamp Says:

    Yeah that makes me wanna quit from the whole retardweb actually ;) I’ve said it a million times, but It will happen soon or later, don’t know about you guys but I get pretty bored by blogging lately, especially when one writes about a topic that needs a ton of preparation, before someone points you on a misplaced vowel, or hack your host instead. Since I have no life anyway, it should be time to create one :D I’m thinking of only releasing papers and just leetware once a month, would be a nice shift, especially this year.

  4. maluc Says:

    Yea, it’s not just %22 but several other HTML injection characters.. had a similar conversation with some last week about it which i’ll paste below. It’s nice that they’re trying, but i’m a bit cynical that it added any actual security to the intarwebs.

    “You’re right about it not working in firefox, but it does work in IE7. The
    reason is that firefox automatically hex encodes certain XSS enabling
    characters and any in the upper range of the ASCII table (above %A0). It
    encodes (for XSS safeguarding) the following characters: space,”,>,doDownload(1) HTTP/1.1

    GET /test.asp?%3Cscript%3EdoDownload(1)%3C/script%3E

  5. maluc Says:

    well wordpress choked on the less than signs as i thought it might.. so here it is repasted - hopefully correctly.

    You’re right about it not working in firefox, but it does work in IE7. The
    reason is that firefox automatically hex encodes certain XSS enabling
    characters and any in the upper range of the ASCII table (above %A0). It
    encodes (for XSS safeguarding) the following characters: space,”,>,<,`.. and
    changes a new line (%A0) to a space (%20). For that hyperlink, the requests
    the two browsers actually make are like this:

    GET /test.asp?<script>doDownload(1)</script> HTTP/1.1

    GET /test.asp?%3Cscript%3EdoDownload(1)%3C/script%3E

  6. kuza55 Says:

    Yep, I’ve found this discrepancy particularly relevant in DOM Based XSS vulns when document.location isn’t unescaped, but written directly into a html parameter as-is, which is (as you mentioned) safe in Firefox, but not IE.

  7. Wladimir Palant Says:

    Yes, this escaping makes a whole lot of XSS vectors to fail - and it will work even better in Firefox 3 (

  8. alfredo melloni Says:

    the problem is always in the web application. You can use which browser do you want but every user input must be validated :P

  9. Awesome AnDrEw Says:

    I’ve never really had to work with any other character sets outside of UTF-8 when dealing with XSS, but are the others effected by Internet Explorer 8 as well? And Ronald, before you decide to quit the internet give us a “heads up” so I can ask you about certain issues you seem to know a lot about.

  10. Felstatsu Says:

    I’m not too convinced by the early death thing. You actually have a job and get out of the house, so you’re not sitting at the comp blogging 24/7. You’ve mentioned before going out to meet up with people, going to conventions, meetings, etc which all mean you’re a lot more active and healthy than the “going to die an early death blogger”. I get the feeling you’re going to stick around and educate people on security for a good long time.

    Was the testing looking for sites vulnerable to some particular exploit (maybe more accurately not secured against their users being vulnerable to some exploit but w/e)? I can’t really think of any other testing where you’d come to the “Firefox = less good for testing” conclusion, but I’m behind enough on my sleep I know my mind isn’t working too well right now. I’m a little curious what the testing actually was (so I can know to test in IE too), but unless I got it in one the correct sequence of neurons to get the right answer simply aren’t working right now.

  11. RSnake Says:

    @Felstatsu - hahah, yah, let’s hope I don’t leave toooo pretty of a corpse. A wrinkle or two can’t hurt.

    The testing was actually using a proxy, I was seeing the vulnerably if I modified the query string, but not if I just threw it into Firefox’s URI field. IE though I could. Simple enough. It just makes it harder to test using Firefox since it behaves differently and will miss some vectors. It means I just have to use a proxy, made the config changes suggested above or use IE for testing.

  12. Felstatsu Says:

    Ahh, I see I was fairly far off target, should have stopped for coffee that morning when I had the chance to.

    Thanks for the post and response, definitely some info I’ll have to keep in mind for future use.