On 24/12/2013 18:06, Jeremy Boynes wrote: > On Dec 24, 2013, at 2:29 AM, Mark Thomas <ma...@apache.org> 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 = <the OCTETs making up the > field-value and consisting of either *TEXT or combinations of > token, separators, and quoted-string> > > where TEXT is defined in 2.2 as TEXT = <any OCTET except > 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 same applies to cookie values. This impacts how quoting, escaping, unquoting and unescaping is handled for cookies. Way forward There are so many individual issues here that it is hard to keep track of everything. Worse, potential solutions to some issues impact on other issues. I'm struggling to figure out how we might best organise this discussion so that we can reach some decisions on how to change the cookie parsing and document those for future reference. I'm wondering if a wiki page or set of pages might help. Use the wiki to document current thinking, discuss things on list updating the wiki as we go and, when we are happy, transfer the docs from the wiki to the Tomcat docs ending up with a cookie equivalent of this page: http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html To be clear, I suspect that my veto for r1553187 will be withdrawn and the patch (or something close to it) applied but given the past experience of the problems that have accompanied any change to the cookie parsing I think we need to think about this and discuss it a lot more first. Thoughts? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
