httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject navigator charset bug
Date Mon, 20 Mar 2000 06:12:00 GMT
One of the patches I added was to Apache was to add an explicit charset
parameter to the content-type header on any default error/etc. messages
generated by Apache.

Fair enough, since the generated messages are written in a specific
charset.

The problem is that, due to a bug in Navigator, this is causing problems
for people.  The bug in Navigator is that if you issue a redirect,
with an explicit charset in the HTTP headers, to a document that does
not explicitly specify a charset, then Navigator will use the
charset specified in the redirect.

Unfortunately, this gets even worse WRT the "cross site
scripting" problem, because it means that if you don't specify an explict
charset for a document, then an attacker can fool Navigator into using 
utf-7 or something equally dangerous.  eg. in utf-7, "+ADwK-" is the same
as "<".

So, in this example, you have something like:

	HTTP/1.1 301 Moved Permanently
	Date: Mon, 20 Mar 2000 04:58:57 GMT
	Server: Apache/1.3.12 (Unix)
	Location: http://search.travel.yahoo.com/search/ftravel?R=travel&p=%2BADwK-script%2BAD4K-alert(document.cookie)%2BADwK-/script%2BAD4K-
	Connection: close
	Content-Type: text/html; charset=utf-7

being generated, which then loads the specified document, that doesn't
specify an explicit charset and, due to the charset in the redirect,
causes Navigator to load it as a utf-7 doc.

While this is why the add default charset stuff was added, it wasn't
previously thought that it was anywhere near this widely exploitable.  
Before, it was thought that the user either had to use IE and explicitly
enable its autoselect charset option or explicitly specify utf-7 in their
browser.

The reason this causes a problem is when people rely on the browser
magically guessing the right charset to use.  In that case, Navigator will
use iso-8859-1 because that is what we specify in the redirect, when
before it guessed, and guessed right for certain users a certain large
percent of the time.  So this breaks existing functionality in a way that
there is no config option to change.

Suggestions?  Using a meta tag in the error document instead of a
charset paramaeter in the HTTP headers supposedly avoids that, but
I really don't want to do that, both for conceptual and implementation
reasons.


Mime
View raw message