The attack vector, which he calls "Session Confusion" is something that arises when a server is serving up multiple apps/domains/subdomains, and using the same key issuance scheme for sessions across them, without tying them to an app or domain. This can lead to incorrect logic from app developers, e.g. "Anyone with a valid session key for this app must have been granted the key by this app, and therefore have gone through the signup logic."
Timely -- I've just been digging through the state of play on session management for web apps, something I haven't worried about for 20 or so years, and the documentation out there is surprisingly chill with regards to best practices, security considerations, etc. I wanted a sort of cookbook that like djb had approved, and there is no such thing that I can find.
This is a good writeup and a surprising bug!
For the average web app, it feels like JWT introduces some complexity (and footguns like this) for no real benefit. I mean, you can avoid a session lookup from redis or something, but that's hardly an expensive part of a request. You can always optimise hot, non-session requests (e.g. private image serving can use signed URLs)
Also, you can't revoke sessions ns unless you have a revocation list, in which case, why not just have a session list?!
Genuinely interested in real use cases for JWTs.
One advantage revocation lists have over session lists is that they can be distributed via a bloom filter. Assuming multiple services need to validate against some shared auth service, this can be a significant reduction in round trips.
According to my understanding, RFC 6265, and MDN, removing the leading dot from the cookie's domain shouldn't have changed whether or not it was sent to subdomains (it should have been sent in either case). What am I missing?
Edit: Maybe I'm misreading. I thought the domain was changed from "breakthroughjuniorchallenge.org" to ".breakthroughjuniorchallenge.org" but maybe it was changed from nothing (which might display as "breakthroughjuniorchallenge.org" in browser debug tools but really is a host-without-subdomains cookie) to ".breakthroughjuniorchallenge.org", which should be the same as changing it from nothing to "breakthroughjuniorchallenge.org" too, I think.
I think there is a bit left out - I expect that the cookie was restricted in some other way. Either the logged in experience was on a different sub-domain (e. g. `app.breakthroughjuniorchallenge.org`) or the cookie was restricted to a sub-path (e. g. `Path=/app`). In either case, changing the scope of the cookie would make it available where it wasn't before.
I think you’re right, it was probably the changing from nothing.
I'm impressed by the timeline. Just over two hours from notification e-mail to amendment (and after office hours too).
Me too! I’ve never seen a response so fast, let alone one where they fix the bug. Definitely impressive.