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
