Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability

[Tim <tim-security () sentinelchicken org>]

Hello Yossi,

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
> engineering.

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
why:

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
headers.

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.

tim