I am more afraid of the man at the browser and the man in the browser rather than middleman attacks.
For instance a user might be trying to use your paid service for free or otherwise get information they are not supposed to and if you are using cookies for authentication, authorization or application state, the user could modify the cookie and break your system. Not to mention the cookie is a vector for XSS, buffer overflows, and other troubles.
So if you are sending anything in a cookie that you don't want people to tamper with you should cryptographically sign it, or alternatively, send them a single opaque random identifier that points to a session or request record inside the server. There are way too many cookies on web requests now, and just from the viewpoint of speed, the opaque reference is a performance win in the age of Hazelcast.
Replay attacks can be made but there are many countermeasures, such as adding a timestamp and a nonce.
This defends against the major threat (the would-be user who wants to abuse your web site) vs a more hypothetical case (sophisticated outsider wants something.)
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.
If 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.
The 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.
Cookie 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.
For instance a user might be trying to use your paid service for free or otherwise get information they are not supposed to and if you are using cookies for authentication, authorization or application state, the user could modify the cookie and break your system. Not to mention the cookie is a vector for XSS, buffer overflows, and other troubles.
So if you are sending anything in a cookie that you don't want people to tamper with you should cryptographically sign it, or alternatively, send them a single opaque random identifier that points to a session or request record inside the server. There are way too many cookies on web requests now, and just from the viewpoint of speed, the opaque reference is a performance win in the age of Hazelcast.
Replay attacks can be made but there are many countermeasures, such as adding a timestamp and a nonce.
This defends against the major threat (the would-be user who wants to abuse your web site) vs a more hypothetical case (sophisticated outsider wants something.)