On Dec 26, 2013, at 2:47 AM, Mark Thomas <ma...@apache.org> 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
