Re: Signing Set-Cookie

I disagree that my attitude will lead to disaster — and in fact think quite the opposite, it will avoid disaster — but I appreciate your stance.

The escaping transformation is an interesting idea, and could actually be applied to more than just set-cookie.

We already have a flag that transforms the value, `sf`, and so another flag, `enc` or `b64` is not out of the question. Then the recommendation/requirement would be to use this flag with Set-Cookie and similar fields to avoid this problem.

Before someone asks: No, I do not think this is a good idea to apply to all field values by default.

What do folks think of this?

 — Justin

> On Jun 7, 2022, at 7:34 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> On Tue, Jun 7, 2022 at 10:35 AM Justin Richer <jricher@mit.edu> 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?
> 
> This is the attitude that leads to disaster. Clever attackers will
> find ways in which the assumptions underlying the analysis of the
> harmlessness of the confusion are broken. Its much easier to design
> things to be injective and thus never have to worry, than to have to
> ask about the construction of cookie values each and every time a user
> uses them. This isn't "security purity", it's what's required to
> ensure that users are safe, without having to understand and get the
> details right each and every time. We've learnt these lessons the hard
> way, and it's disappointing to see them get ignored.
> 
>> 
>> 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:
>> 
>> - 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?
> 
> Apply an escaping transformation or some sort of base64 before turning
> into a List.
> 
>> 
>> — Justin
> 
> 
> 
> --
> Astra mortemque praestare gradatim

Received on Wednesday, 8 June 2022 16:23:26 UTC