Konstantin Kolinko wrote: > 2009/6/11 Mark Thomas <ma...@apache.org>: >> fha...@apache.org wrote: >>> Modified: tomcat/current/tc4.1.x/STATUS.txt >>> URL: >>> http://svn.apache.org/viewvc/tomcat/current/tc4.1.x/STATUS.txt?rev=783570&r1=783569&r2=783570&view=diff >>> ============================================================================== >>> --- 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 of >>> RFC2616 >>> http://people.apache.org/~markt/patches/2009-03-03-broken-browser.patch >>> - +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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
