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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080517225555.GB14452@sentinelchicken.org>
Date: Sat, 17 May 2008 15:55:55 -0700
From: Tim <tim-security@...tinelchicken.org>
To: yos20053@...il.com
Cc: bugtraq@...urityfocus.com
Subject: 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