- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Tue, 7 Jun 2022 16:34:38 -0700
- To: Justin Richer <jricher@mit.edu>
- Cc: Willy Tarreau <w@1wt.eu>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
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 Tuesday, 7 June 2022 23:35:01 UTC