So subdomain takeover looks like the big one, and whether the tradeoffs of token binding are worth it seems to depend on how hard it is to fix poorly scoped cookies.
-
-
Replying to @RichFelker
there are, of course, all kinds of protections available to prevent cookie theft. Token binding is unique in that it can prevent use after theft rather than trying to stop the theft itself. Both have value. Defence in depth etc. Token Binding also ...
1 reply 0 retweets 0 likes -
Replying to @__b_c @RichFelker
... can apply to things like OAuth and SSO tokens, which don't necessarily have the same characteristics as cookies. The browser case is maybe less compelling b/c of other cookie protections. But it's still useful IMHO. And, for better or worse, ...
1 reply 0 retweets 2 likes -
Replying to @__b_c @RichFelker
adoption and deployment at large likely hinges on the browser supporting it
1 reply 0 retweets 0 likes -
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 -
Rich Felker Retweeted hanno
I think subdomain takeover is actually a much bigger threat than many ppl realize. IIRC
@hanno has some nice work on this. Seehttps://twitter.com/hanno/status/1021350234117599234 …Rich Felker added,
2 replies 0 retweets 2 likes -
I asked Ryan about it, subdomain takeover has the same problem, you could just serve some js that does your attack instead of steal cookie then attack from your machine. I think this is another "why not just use the vector you used to get the cookie in the first place"?
2 replies 0 retweets 2 likes -
fair point but driving a whole attack from js served from the subdomain is more difficult than doing it directly with the cookie. Raising the bar rather than complete prevention. The same is true for XSS and the httponly flag on cookies but it still exists and gets used.
1 reply 0 retweets 0 likes -
That's true, but you have to admit if httponly was as invasive a change as token binding, it probably wouldn't exist?
2 replies 0 retweets 1 like -
your point is taken. But given that it's optional and only used when negotiated by both parties in the TLS handshake, it doesn't seem that invasive to me.
1 reply 0 retweets 0 likes
The argument I heard was that because this will break Antivirus (I'm the last person who would complain about that), they will just start being more invasive with hooks and patching. That's pretty convincing argument, bluecoat aren't just going to close down the business 
-
-
I took it the other way, IMO, someone at MSFT mentioned it as another way to get endpoint TLS MitM further untenable
1 reply 0 retweets 4 likes -
Replying to @SwiftOnSecurity @__b_c and
Right, but is that good or bad? They can switch to hooking and patching instead - they're going to do that, because they're business depends on that and they already need Admin to install cert. So did we make things better or worse?
1 reply 0 retweets 3 likes - 29 more replies
New conversation -
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.