mailing list archives
Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability
From: Tim <tim-security () sentinelchicken org>
Date: Sat, 17 May 2008 15:55:55 -0700
I've read your previous messages and I'm not convinced.
I think that you didn't understand this vulnerability properly. I ask
to to check again and run this exploit with Firefox. After running this
exploit, change manually the ecnoding in Firefox to UTF-7.. You will see
that the alert will jump up. There is no problem to trick the victim and
force him to change the encoding of his browser by little social
Hmm... just about as easy as convincing a user to blindly accept a
forged SSL certificate or run an executable. At that point, who cares?
But if you, apache guys will set 403 page's charset in the server side
by writing it in your server code, that will prevent this script
running. In IE autoselect will work only if no charset was set to the
page in server side.
So let's see here... You're advocating that all web pages should have
the character set defined in the page source via a meta/http-equiv tag
in order to prevent injections? This is bass-ackwards. Let me explain
Think about what a browser has to do in order to interpret a page.
Before it interprets your meta tag, it already has to guess the content
type, right? If it doesn't know whether it's UTF-32be or UTF-16le, then
it has to guess before it can even locate your meta tag to determine
whether or not the guess was correct. This is just painful and probably
dangerous. http-equiv tags are a terrible idea and are only there
because so many web designers are clueless about how to set proper HTTP
The charset encoding could apply to any text-based content types besides
HTML. Is the meta tag useful then?
Unfortunately, many sites don't set the content-type/charset at all, so
browsers have to do guess work. Don't fault a web server which does set
it explicitly the right way simply because your browser is happens to
let you bend the rules.