adoption and deployment at large likely hinges on the browser supporting it
-
-
Replying to @__b_c @RichFelker
But you dodged Rich's main point, it has to be an attack that can't just be exploited using the same vector you used to get the cookie, right? Subdomain takeover is the first example I've heard that works, but that's pretty niche, you have to admit?
4 replies 0 retweets 2 likes -
Replying to @taviso @RichFelker
didn't mean to dodge so much as try to diplomatically say that I agree that there some limitations to the value prop around the browser/cookie protections but that there are other use cases, like SSO and native OAuth/API, that can benefit
1 reply 0 retweets 1 like -
and that even when there are other attack vectors, I believe there's still value in enabling a cookie to be bound to a client generated asymmetric key because it does prevent the cookie from being used successfully in a different context without also getting the key
1 reply 0 retweets 1 like -
Replying to @__b_c @RichFelker
Sure, it can (depending on if backed by hardware) prevent cookie from being used on another machine...but what attack are you imagining that can't be executed from the compromised machine instead? This is my main sticking point.
2 replies 0 retweets 2 likes -
Replying to @taviso @RichFelker
stealing cookie from a workstation left unlocked for a couple minutes while someone gets coffee
2 replies 0 retweets 0 likes -
wait, the premise of the attack is that you have local, authenticated access for the time needed to steal a cookie, and that is the attack you hope to protect against with a browser feature?
1 reply 0 retweets 2 likes -
it's an example
2 replies 0 retweets 0 likes -
Is there a more practical one? It's unreasonable to expect the browser to protect against this type of attack. The hardware and OS should, and the user failed to close the loop by locking the device. This is a game over scenario on almost any platform.
1 reply 0 retweets 1 like -
It's the browser supporting features that allow a site to protect against it. And against replay after any leakage (log files for example) that's more passive and isn't a direct vector into the machine. And those kinds of things do happen.
1 reply 0 retweets 0 likes
Yeah, slightly reducing the impact of logfiles leaking (if they contained unredacted cookies - doesn't help if passwords or PII is in there, I think that's more common cookies leaking, e.g. apfs) seems like the first valid attack I've heard. You have to admit it's not strong?
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.