Protecting against cookie/session re-use with a sequence generator

Question

I might be completely making this up as a solution or even feasible. I have a situation where a cookie exists for a browser/user/tab. In the background, while the user is viewing a page a request is made regularly to the backend. The cookie is passed as part of this flow. The backend updates the cookies content each time the request is made. The cookie's content is encrytped so its unreadable from the fronend browser. The Set-Coookie header is used to get the browser to update the cookie. All good so far.

The system falls down if a bad actor were to have one tab open which polls in the background for the cookie update, but uses another tab (on the same site), with the original cookie, however doesn't allow the second tab to actually adhere to setting the cookie with Set-Cookie - i.e the cookie will always be the value from whatever the first tab has set it as, not the second tab.

I think what I need is a way to stop cookie reuse. For this to work I either need some key value store that keeps track of all historical cookies for a user (could be alot of information) but what I think would work is if I knew the value of a previous cookie and could work out if a cookie was generated from the value of this previous one - I think this would mean I only ever need to store the previous cookie, anything that is not generated from a value of this one is invalid.

I'm thinking of storing within the cookie data a "seed" a bit like a random number generator uses. This seed is used to generate a value which is stored in the next cookie. Its random in as much as anyone else knows but if you know the seed from the previous cookie, you can "predict" what the value will be in the next cookie. If its not that, its invalid. I sort of got the idea from blockchain blocks and the known next block etc.

Is there a formal method to doing this anyone can point me in the direction of. The requirements are that the cookie content changes very regularly so storing a history of all previously used cookies is unfeasible.

Or I might not be understanding and there is another better way entirely?

Answer 1

First: define your threat model. What are you protected and why cookie re-use is a problem.

Second: don't think an attacker will use a browser tab for navigating and another browser tab for attacking. Assume they will use a script, a proxy, a specialized tool, and not a browser. So Set-Cookie header does not mean anything.

If cookie stealing is the issue, you can solve it by correlating a couple client-side values on each request and invalidating the cookie if too much changes. You can have screen resolution, browser version, OS, installed fonts, and the IP address. If two or more of those changed, the cookie probably has been stolen.

An attacker can change those markers anytime, because the code runs on his side, but a victim won't send those markers to an attacker, and self-attack is not something you have to concern yourself with.

Answer 2

Most modern web frameworks have the concept of a server-side user "session".

You say your cookie is fully encrypted anyway, so all you have to do is add a unique variable to the cookie that is also added to the user's session. When you change the cookie, change the variable in both the cookie and the session.

This will automatically invalidate the old cookie and the most recent cookie will be the only working version because its variable matches the session's.

(Make sure you compare the variable in the cookie with the variable in the session in each request, if there is a mismatch, logout the user)