Paid Advertising
web application security lab

UTF-7 Strikes 404 Pages In Internet Explorer

There’s been an interesting thread on bugtraq over the last few days around UTF-7 and Internet Explorer (if autodetection of character encoding is turned on) when submitting a file that is not there to a webpage hosted on an Apache server. Eiji James Yoshida disclosed this issue - which was partially already known (at least by a few people). The problem is that Internet Explorer builds a custom error page, so it’s not particularly useful by itself. I looked into this when I first put the UTF-7 vector on the XSS cheat Sheet

However, what Paul Szabo discovered is that if you make the URL at least 512 bytes in length it will no longer return IE’s custom 404 error page, but instead show you the actual error page that you requested:


This equates to essentially a universally useful XSS exploit, given those conditions against an Apache server with default 404 error pages. Granted, it does require the automatic character set detection, but still. Pretty scary stuff. Looks like Apache needs to either start encoding the output or otherwise protecting itself from UTF-7 injection, and indeed Internet Explorer shouldn’t have character restrictions on displaying their custom 404 page. Either (or both) of those would fix the issue.

4 Responses to “UTF-7 Strikes 404 Pages In Internet Explorer”

  1. yawnmoth Says:

    I wouldn’t call Paul Szabo’s observation a discovery since it’s documented behavior on Microsoft’s website:

    “…to see the exact text of an HTTP 500 response, the content length must be greater than or equal to 512 bytes. ”

  2. RSnake Says:

    Thanks for the clarification, yawnmoth. It also might not work at all (I had to manually switch my encoding to get it to work)… I was talking with Brian Eaton about this and he had a good point. Here’s what he said:

    Paul Szabo noticed an Apache server that wasn’t setting a charset tag on 404 responses, leaving the server open to UTF-7 CSS attacks. He originally thought this was due to an Apache bug, but I think the root cause is actually a badly designed ErrorDocument handler.

    I haven’t been able to verify other than doing it by hand.

  3. Chris Shiflett Says:

    With a fresh Apache 1.3.36, the Content-Type header in a 404 response does indicate an encoding. My guess is that Brian Eaton is correct.

  4. RSnake Says:

    Well here it is from the horse’s mouth:

    Seems that I was wrong and Brian Eaton was right: default apache installations seem to return an explicit charset in their error message. (Now I cannot explain how I convinced myself otherwise.) Then there is no Universal XSS against default Apache webservers…


    Paul Szabo