Re: Signing Set-Cookie

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 07, 2022 at 01:31:55PM -0400, Justin Richer wrote:
> 
> While I agree that the combination could potentially be problematic,
> and definitely is distasteful from a security purity standpoint, what
> I’m not seeing is an attack where two distinct non-theoretical valid
> values of Set-Cookie could be combined into another valid Set-Cookie
> header. Yes in theory there’s a comma in the syntax, but I’m not
> seeing how that could be used to mount an actual attack in a
> meaningful way. The two Set-Cookie headers combined would need to have
> the exact same content as the single Set-Cookie header on its own, but
> be interpreted in a different way by the verifier in such a way that
> would affect the application. The attacker here isn’t substituting a
> completely different value, and is not adding a value where one wasn’t
> before. Can someone please give me a concrete demonstration that shows
> this is something we should actually protect against and not just
> something to warn against?

As some others have said, this kind of reasoning is dangerous. Attackers
seem to be much more inventive than defenders. :-)

Looking at the the Set-Cookie syntax, it seems that the actual cookies
can not cause trouble, it is future-extension attribute-values that can
get confused. However, the grammar looks just odd (even in RFC6265bis),
as both quoted and unquoted forms seem to share the same character set,
which, for example does not include comma. This looks like an error in
the spec (but might be intentional?).

However, given how messy cookies are, I would not be surprised if there
are endpoints that send unquoted cookies with commas and spaces in it,
and expect the thing to work.


> Regardless, what is the recommended approach? Martin’s seems to be
> “throw out HTTP Signatures entirely”, but he’s said that since the
> work started. :) What I think though is that we’ve got a few potential
> approaches:

Realistically, I do not see much overlap between HTTP signatures and
set-cookie. Cookies are mostly associated with browsers, and:

- I do not expect signatures to have much use there.
- I expect other applications to use other mechanisms to accomplish
  similar goals as of using cookies in browser.
- I expect set-cookie to be privileged in browsers, not disclosed to
  scripts (since httponly cookies exist).

>  - Never sign Set-Cookie
>  - Never sign multiple Set-Cookie headers
>  - Have a special syntax for dealing with Set-Cookie (probably a
>    derived component, but I’m not thrilled about this one)
>  - Warn against weirdness with multiple Set-Cookie headers
> 
> Any other approaches?

Dirty hack, Use ASCII RS (0x1E) as separator for set-cookie. :-) 

But one might still need to be bit careful with that. Even if some
endpoint treats RS in HTTP/1.x as instantly fatal to connection, it
might still be accepted in HTTP/2 (since the header encoding is 8-bit
clean). In HTTP reverse proxy I have written, RS is not allowed in
HTTP/2, however the code that disallows that is entierely separate
from the code that disallows it in HTTP/1.x.


-Ilari