Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability
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