New CS proposal: Cookie Theft Detection Cheat Sheet

[Jxck]

What is the proposed Cheat Sheet about?

The way to detect compromised Cookie, for avoid Session Hijacking.

What security issues are commonly encountered related to this area?

Since authorization process has been updated via Passkey, 2FA etc,
It's so difficult to attack services with compromised Passwords.
So attacker sifting vector to steal Session Cookie and use it to hijack user session.
It saids that Pass the Cookie attack and leaked Cookies are traded at Dark Net.

See more details: Cookie stealing: the new perimeter bypass – Sophos News

It's so difficult to detect Cookie Theft attack since there are no difference between
Real User & Attacker while they sends same valid session cookie.

I believe every services are affected by this kind of attack but there are less informed how to protect.

Recently, Slack shares their own knowledge to prevent this attack.

Catching Compromised Cookies - Engineering at Slack

I wonder lot's of big services already doing the prevention like above, but less informed to public.

OWASP cheat sheet is the best place to publish knowledge around here.

What is the objective of the Cheat Sheet?

No guideline around Cookie Theft attack in current cheat sheet.

What other resources exist in this area?

Slack shared their experience and it seems good resource to start discussion.

Catching Compromised Cookies - Engineering at Slack

[szh]

This is really interesting. Are there any other orgs that have discussed if/how they're handling this threat? I'd like to see multiple sources for a more complete view rather than relying on just one company.

[Jxck]

@szh Good Question and I can't find.
I believe GAFAM-ish company doing the protection like this but there're no outreach around here (I imagine it's blocked by security reason).
Slack's blog is the first resources I've ever seen, thanks for Slack!

I hope the discussion here will gather knowledge, merged into guideline and share to every services who afraid cookie theft.

[Jxck]

I wanna loop in author of Slack's blog here @Glitched

[Glitched]

Hey! Glad to hear you found the blog post useful. I'm not speaking on behalf of Slack here, just my personal interest in the problem:

Protecting against a compromised endpoint is a hard problem, but there are a lot of ways to make progress without as complex a solution as detailed in out blog post. First, I'd suggest a reasonable expiration time on cookies. If a cookie is only valid for a week, the odds are it's still valid when an attacker tries it will be much lower. (From my understanding, the people operating the malware are often not the same people using the cookies, so a time delay may be introduced.) Anything is better than having valid cookies sitting around for months.

Another mitigation might be storing info from the user agent on the session object. If a user created the session on Chrome, I wouldn't expect to see that cookie coming from Edge. I might expect to see a token from an older version of Chrome being used in a newer version of Chrome, but not the other way around. If the user started on a Mac, I wouldn't expect to see the session coming from a Windows machine. It might be worth calling out that iOS devices can sometimes present as macs if you set the "use desktop view" option.

Alternatively, consider teleportation checks. If a user attempts to use a session with an IP address with a location far away from where the session was created, it might be reasonable to ask the user to reauthenticate (or 2FA again).

All of those solutions are definitely incomplete, but they're not nothing! I'm very excited about the Device Bound Session Credentials (DBSC) proposal from Google, which aims to prevent sessions from leaving a particular device using hardware TPMs. The Chromium blog has high-level a overview, too. Microsoft also proposed an addon to DBSC, Device Bound Session Credentials for Enterprise. I'm not sure if the timelines are still on track, but the Github repo says they'd like to have a DBSC trial working by the end of the year.

In the meantime, I'm interested in Session-Lock, which aims to do something similar.

[Jxck]

Thanks for your additional information !

Yes, DBSC is the fundamental solution for this kind of attack, but it's just early stage to standardize. During the work go forward and every device will have TPM, Server side solution should cover problem.

Checking session meta information ((geo)-IP, UA, Sec-Fetch-* etc) could mitigate some attack, even if they can't manage timestamp like Slack does. I think it's can be a 1st Tier recommendation is this Cheat Sheet. And hope some other additional Tier as Defense in Depth manner.

In the meantime, I'm interested in Session-Lock, which aims to do something similar.
TIL Session-Lock, thanks !

[Jxck]

I started drafting roughly.

https://docs.google.com/document/d/1eENyNg9ivICHQpUp6OyLFoarNZXoM8Bfk9__3cTTwXI/edit?tab=t.0

Feel free to comment me.

[jmanico]

There are several problems with this work as is.

1. We have cookie guidance in other cheatsheets, I would like this brief work to go there
2. There are comments like "session theft is basically the same as credential theft" which is not true. I may steal your session but without your credentials I cannot do re-authentication challenges.

This needs to be matured in a few ways before we can use it.

[Jxck]

@jmanico

1. We have cookie guidance in other cheatsheets, I would like this brief work to go there

I don't against that. (I think you mean Session Management)
I can send PR for session management cheat sheet. but I'm worried that the document might be too long.

2. There are comments like "session theft is basically the same as credential theft" which is not true. I may steal your session but without your credentials I cannot do re-authentication challenges.

Yes, it's meant for "stealing session". I updated with adding "util it's expires".