tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
Date Thu, 11 Jun 2009 19:41:04 GMT
Konstantin Kolinko wrote:
> 2009/6/11 Mark Thomas <>:
>> wrote:
>>> Modified: tomcat/current/tc4.1.x/STATUS.txt
>>> URL:
>>> ==============================================================================
>>> --- tomcat/current/tc4.1.x/STATUS.txt (original)
>>> +++ tomcat/current/tc4.1.x/STATUS.txt Wed Jun 10 23:34:57 2009
>>> @@ -28,5 +28,5 @@
>>>  * Provide a partial work-around for browsers that ignore charset requirements
>>>    RFC2616
>>> -  +1: markt
>>> +  +1: markt, fhanik
>> Folks,
>> This patch is the only thing between me and a 4.1.40 tag. It needs one
>> more +1. Any time people have to look at this will be much appreciated.
>> Mark
> It is odd to see that encoding is being set after obtaining a writer,
> but the old code does effectively the same, isn't it? May be I do not
> understand something...

RFC2616 requires that responses without a charset in the content type
must be treated as ISO-8859-1. A number of browsers ignore this and try
and guess the type. This makes the browsers vulnerable to a UTF-7 based
XSS attack. The browser vendors view guessing the charset as a feature.
The Tomcat and httpd security teams view it as non-spec compliance that
leads to a security vulnerability.

As a result of a reported UTF-7 XSS vulnerability (it was rejected by
both the httpd and Tomcat security teams as a browser issue) we reviewed
the options available in Tomcat for sysadmins to work-around this
browser 'feature'.

For all versions, app developers can provide their own valve or filter
to address this issue.

TC5 & TC6 have STRICT_SERVLET_COMPLIANCE which ensures a charset is
always sent with the response. We also added the AddDefaultCharset
filter to trunk. This mimics httpd's AddDefaultCharset directive.

For Tomcat 4 the error reporting valve provided a code path where a
UTF-7 XSS code be triggered. Unlike 5.5.x and 6.0.x there was no simple
config option that would prevent this. Hence the change in the patch
above that prevents this by ensuring that the response sent to the
browser includes a charset.

So in short, the patch is a sticking plaster for a browser
vulnerability. Since the browser issue has been discussed at great
length in public, this wasn't handled on the security list.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message