Re: 8-bit text in cookie values, was: svn commit: r1553187
On 24/12/2013 18:06, Jeremy Boynes wrote: > On Dec 24, 2013, at 2:29 AM, Mark Thomas wrote: > >> On 23/12/2013 19:15, jboy...@apache.org wrote: >>> Author: jboynes Date: Mon Dec 23 19:15:35 2013 New Revision: >>> 1553187 >>> >>> URL: http://svn.apache.org/r1553187 Log: fix #55917 by allowing >>> 8-bit ISO-8859-1 characters in V0 cookie values >> >> -1 (veto) >> >> The Tomcat community has (to date) always taken the view that >> cookie headers should be restricted (as per RFC2616 section 4.2) >> to "combinations of token, separators, and quoted-string". >> >> That does not permit 0x80 to 0xFF in tokens. > > I thought the V2 patch had addressed your concern about limiting > cookie names to tokens so went ahead and applied it. I thought your proposal was to fix the issue with not allowing 0x80 to 0xFF in quoted strings in V1 cookies. That is a clear bug and I can't see any issues in fixing it. (It probably needs fixing for setting and parsing cookies.) > RFC2616 4.2 defines “message-header” as message-header = field-name > ":" [ field-value ] field-name = token field-value= *( > field-content | LWS ) field-content = field-value and consisting of either *TEXT or combinations of > token, separators, and quoted-string> > > where TEXT is defined in 2.2 as TEXT = CTLs, but including LWS> > > The change only allows these characters in values if version == 0 > where Netscape’s rather than RFC2109’s syntax applies (per the > Servlet spec). The Netscape spec is vague in that it does not > define “OPAQUE_STRING" at all and defines “VALUE” as containing > equally undefined “characters” although historically[1] those have > been taken to be OCTETs as permitted by RFC2616’s “*TEXT” variant > of “field-content.” The change will continue to reject these > characters in names and in unquoted values when version != 0 > (RFC2109’s “word" rule) This is the sort of ambiguity that makes me nervous. I'll expand on that at the end of this e-mail. > I don’t want to proliferate them but would it help to add another > system property gating this behaviour? Perhaps with 3 values: > “reject” (the default, causing an IAE as now), “skip” (logged but > not returned to the application), and “allow” (returned to the > application). I'd prefer to avoid yet another system property if at all possible. The only reasons not to do this are security or backwards compatibility. If security is an issue it should never happen. Backwards compatibility should be able to be handled with a Context option rather than a system property. > Thanks Jeremy > > [1] based on comments by Fielding et al. on http-state and what > I’ve seen in the wild Can you provide references for [1]? Security concerns The security issues around cookies have usually involved something along the following lines: - target application sets a cookie - malicious application sets a cookie - client returns both cookies to Tomcat - Tomcat parses cookie header - something, somewhere goes wrong and some/all of the cookie from the target app is exposed to the malicious application The various things that (could) have gone wrong: a) Tomcat doesn't generate the Set-Cookie header correctly which causes the client to merge the cookies b) The client mis-handles the cookies causing them to merge c) Tomcat doesn't parse the cookie header correctly and ends up merging the values To prevent a) we need to ensure that the Set-Cookie header we generate is specification compliant. This is relatively simple. To prevent b) we need to ensure that the Set-Cookie header is specification compliant *and* takes account of known issues with Set-Cookie handling by clients. This is not so simple since the known issues often mean sending a header that is not specification compliant. To prevent c) we need to ensure that our Cookie header parsing is specification compliant and that and relaxation we allow does not permit a malicious application from manipulating how the header is parsed. This is primarily why, currently, an IAE is thrown. If the cookie header is invalid then throwing an IAE ensures that no mischief can take place. A significant complicating factor is the ambiguity of the Netscape specification. The security problems tend to occur when client and server view one or both of the cookie headers differently and with V0 cookies that is very likely. Random information This has been at the back of my mind and here seems like as good a place as any to document it. With the various parts of the Servlet API that give direct(ish) access to HTTP headers (setHeader etc.) the Tomcat developers have always taken the view that: a) Tomcat will not blindly use the value directly but validate it and (where possible / necessary) escape it so it can be used b) Applications should be able to use methods symmetrically. i.e. If they call setHeader() with a given value and if that header is echoed by the client then calling getHeader() should return exactly the same value. The
[Bug 55933] tomcat hangs when try to request wsdl defination from jax-ws
https://issues.apache.org/bugzilla/show_bug.cgi?id=55933 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Mark Thomas --- There is not enough information in this report to enable a Tomcat developer to even begin to try and reproduce this. Please follow up on the users mailing list and - if there is a problem here - please feel free to re-open this bug once you have a suitable description of the issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 8-bit text in cookie values
On Dec 26, 2013, at 2:47 AM, Mark Thomas wrote: Focusing on the 8-bit issue address by the patch, leaving the other RFC6265 thread for broader discussion ... >> The change only allows these characters in values if version == 0 >> where Netscape’s rather than RFC2109’s syntax applies (per the >> Servlet spec). The Netscape spec is vague in that it does not >> define “OPAQUE_STRING" at all and defines “VALUE” as containing >> equally undefined “characters” although historically[1] those have >> been taken to be OCTETs as permitted by RFC2616’s “*TEXT” variant >> of “field-content.” The change will continue to reject these >> characters in names and in unquoted values when version != 0 >> (RFC2109’s “word" rule) >> >> [1] based on comments by Fielding et al. on http-state and what >> I’ve seen in the wild > > Can you provide references for [1]? This is the mail in the run up to RFC6265 that triggered the discussion: http://www.ietf.org/mail-archive/web/http-state/current/msg01232.html The relevant bit was: > Changing the ABNF > to include base64 does not do that -- it is just another > fantasy production that differs from all prior specs of > the cookie algorithm. Changing it to > > cookie-value = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF > > or just the minimum > > cookie-value = %x21-2B / %x2D-3A / %x3C-7E > > returns the definition to the original Netscape spec (at > least in the first case), reflects how they are implemented > on the Internet, and eliminates this artificial distinction > between the server and user agent requirements. with the observation that the rule including %x80-ff was the one matching the Netscape spec. The RFC6265 editor actually chose the latter production which led to the following exchange http://www.ietf.org/mail-archive/web/http-state/current/msg01234.html http://www.ietf.org/mail-archive/web/http-state/current/msg01236.html asserting that the support for 8-bit characters implied by *TEXT was implicit in the original Netscape spec. In this message: http://www.ietf.org/mail-archive/web/http-state/current/msg01207.html Roy asserts that the cookie-value = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF production would be needed to support cookies currently in the wild, including the issue with the __utmz cookie that I’ve seen. Further discussion resulted in the final production: cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E ; US-ASCII characters excluding CTLs, ; whitespace DQUOTE, comma, semicolon, ; and backslash on the basis that setting headers with the top bit set was deemed a bad idea by httpbis (I don’t have a reference for that). It was noted though that conformance to this was qualified by "Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar” which discourages 8-bit values but still allows them to be sent and means that parsers receiving a cookie value need to be prepared to handle them. Given cookies with these values may be set by other servers in the domain and are sent by user agents, failing hard as we do now prevents the application handling the request at all. The patch tolerates those characters and lets them through to the application. I don’t know of any security issue there given they are being decoded as ISO-8859-1 rather than UTF-8. I believe it’s backwards compatible in that the consequence to the application is that it will now see the request with a cookie that it either expects or that it would be ignoring anyway (on the basis that the cookie would be present if it didn’t have an 8-bit character). The patch does not change the generation behaviour so any attempt to set a V0 cookie value containing one of these characters will still cause an IAE from HttpServletResponse#addCookie(). Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
[VOTE][RESULT] Release Apache Tomcat 8.0.0-RC10
alpha: markt, jfarcand, remm, yoavs, violetagg, rjung Andrew Carr (non-binding) No other votes were cast. The vote therefore passes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r3986 - /dev/tomcat/tomcat-8/v8.0.0-RC10/ /release/tomcat/tomcat-8/v8.0.0-RC10/
Author: markt Date: Thu Dec 26 23:46:27 2013 New Revision: 3986 Log: Release 8.0.0-RC10 Added: release/tomcat/tomcat-8/v8.0.0-RC10/ - copied from r3985, dev/tomcat/tomcat-8/v8.0.0-RC10/ Removed: dev/tomcat/tomcat-8/v8.0.0-RC10/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r3986 - /dev/tomcat/tomcat-8/v8.0.0-RC10/ /release/tomcat/tomcat-8/v8.0.0-RC10/
Author: markt Date: Thu Dec 26 23:46:27 2013 New Revision: 3986 Log: Release 8.0.0-RC10 Added: release/tomcat/tomcat-8/v8.0.0-RC10/ - copied from r3985, dev/tomcat/tomcat-8/v8.0.0-RC10/ Removed: dev/tomcat/tomcat-8/v8.0.0-RC10/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1553605 - /tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java
Author: markt
Date: Thu Dec 26 23:59:25 2013
New Revision: 1553605
URL: http://svn.apache.org/r1553605
Log:
Fix NPEs in test
Modified:
tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java
Modified:
tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java?rev=1553605&r1=1553604&r2=1553605&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/core/TestDefaultInstanceManager.java
Thu Dec 26 23:59:25 2013
@@ -24,6 +24,7 @@ import org.junit.Test;
import org.apache.catalina.Wrapper;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.startup.TomcatBaseTest;
+import org.apache.jasper.servlet.JasperInitializer;
public class TestDefaultInstanceManager extends TomcatBaseTest {
@@ -73,6 +74,8 @@ public class TestDefaultInstanceManager
StandardContext ctxt = (StandardContext) tomcat.addContext(
null, "/test", appDir.getAbsolutePath());
+ctxt.addServletContainerInitializer(new JasperInitializer(), null);
+
// Configure the defaults and then tweak the JSP servlet settings
// Note: Min value for maxLoadedJsps is 2
Tomcat.initWebappDefaults(ctxt);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC10
On 24/12/2013 23:42, Rainer Jung wrote: > On 19.12.2013 19:38, Mark Thomas wrote: >> The proposed Apache Tomcat 8.0.0 release candidate 10 is now available >> for voting. As always, many thanks for the detailed review. > - One special observation in unit tests: Test > org.apache.catalina.core.TestDefaultInstanceManager throws 3 > NullPointerExceptions, that seem to indicate a broken test (see below). Fixed. > - JMX shows that websocket filter is configured for all default apps. > I didn't check, where this comes from, but should it really be > active by default? It is working as designed - whether the design is right is a different question. I have a TODO to provide a container specific way to disable unwanted SCIs on a per context basis. > - MBeans "Catalina:context=/...,host=localhost,type=WebResourceRoot" > and > "Catalina:context=/...,host=localhost,name=Cache,type=WebResourceRoot" > very similar in name (same type). > All of the numeric data moved from the first to the second > (plus additional interesting data in the second), in the first it > is only left traceLockedFiles, stateName, cachingAllowed, > traceResources and allowLinking which is all boolean or enum type. > Should we make the two MBeans differ by "type"? My primary motivation here was to a) move all the caching attributes to a new JMX object and b) have the cache appear as a "sub-object" to the resources when using JConsole with default options. I'm happy with any tweaks folks want to make as long as those two requirements are met. > - Same MBean: new attributes traceLockedFiles (boolean) and > traceResources (Array): should the second be named tracedResources > (additional "d") to distinguish the Array list of resources from the > boolean to trace or not to trace switch? I need to do some clean-up here. I also need to align attribute names between the Context and the Cache. This is on my TODO list for the next release. Thanks again, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1553608 - /tomcat/trunk/webapps/docs/config/http.xml
Author: markt Date: Fri Dec 27 00:18:32 2013 New Revision: 1553608 URL: http://svn.apache.org/r1553608 Log: Clarify based on feedback on users@ list Modified: tomcat/trunk/webapps/docs/config/http.xml Modified: tomcat/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1553608&r1=1553607&r2=1553608&view=diff == --- tomcat/trunk/webapps/docs/config/http.xml (original) +++ tomcat/trunk/webapps/docs/config/http.xml Fri Dec 27 00:18:32 2013 @@ -350,7 +350,8 @@ presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). - + Unless disableUploadTimeout is set to false, + this timeout will also be used when reading the request body (if any). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1553609 - in /tomcat/tc7.0.x/trunk: ./ webapps/docs/changelog.xml webapps/docs/config/http.xml
Author: markt Date: Fri Dec 27 00:20:01 2013 New Revision: 1553609 URL: http://svn.apache.org/r1553609 Log: Clarify based on feedback on users@ list Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1553608 Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1553609&r1=1553608&r2=1553609&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Fri Dec 27 00:20:01 2013 @@ -78,6 +78,10 @@ Add index.xhtml to the welcome files list for the examples web application. (kkolinko) + +Clarify that the connectionTimeout may also be used as the read timeout +when reading a request body (if any). (markt) + Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml?rev=1553609&r1=1553608&r2=1553609&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml Fri Dec 27 00:20:01 2013 @@ -347,7 +347,8 @@ presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). - + Unless disableUploadTimeout is set to false, + this timeout will also be used when reading the request body (if any). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
