3 ms·
What you're talking about is defending the site. That's great and of course you should do that. What the paper talks about is defending the user. The example th
by MichaelGG 11y ago
What you're talking about is defending the site. That's great and of course you should do that. What the paper talks about is defending the user. The example they give is being able to inject cookies then override the GMail chat widget with the attacker's account.
Such an attack doesn't put the site at risk - Google is fine. But it puts Google's users at risk, as they are signed in, yet chatting on another account.
- derefr 11y agoThe point the GP was trying to make, I think, is that if the site's operator has cared enough about their own security to cryptographically sign their cookies, then this provides security to the users as a free benefit, because a MITM wanting to attack the user doesn't have the site's signing key either.
- MichaelGG 11y agoCookie signing doesn't fix this. Attacker will just login, take his own signed, valid, session cookies, shove them into Victim. Now Victim uses whatever.com and Attacker can see. The example they gave was being able to do this to Gmail. Victim is logged into Gmail, but the Gmail Chat widget is logged in as Attacker.
- PaulHoule 11y agoIs there really a difference between attacking the user and attacking the system?
- throwaway000002 11y agoIf you can't authenticate the platform, you can't defend the user, end of story. The web "works" insofar as it does because of the margins of abuse are tolerable. I'm sure those working in "ad tech" have different ideas of how tolerable the abuse is. I've always wondered about how banks deal with it, but having read through my bank's online ToS, I'm happy with my level of liability, because they're clearly willing to take on more risk than I would given the situation.