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".

[mackowski]

@jmanico what do you think about @Jxck response to your questions?

[jmanico]

Ok let's do a new cheatsheet then. This really is a specialized topic. I agree it might be too long.

[kwwall]

Ok let's do a new cheatsheet then. This really is a specialized topic. I agree it might be too long.

I agree that it may be too long, but rather than placing it in a separate cheat sheet, why not just put the content in a new collapsible section under the Cookies section of the Session Management Cheat Sheet? We'd inevitably want a link to this new content from there anyhow.

Why my objection?

I am concerned about the proliferation of new cheat sheets for specialization purposes. More isn't always better (says Mr TL;DR. 😏) Before we had collapsible sessions, this made sense, but I think it makes less sense once GitHub started supporting those. (And we still can put an 'cookie_theft' anchor tag there of someone wishes to link directly to the content.) The reason for my concern is that I'm now at my 3rd employer where the company writes their own custom vulnerability templates for various vulnerability categories. And at all 3 companies, the Additional Resources section of the ones I and most other colleagues written almost always had links to these 3 document sources:

1. OWASP Cheat Sheet
2. OWASP Top Ten reference (when applicable)
3. MITRE CWE reference

So, let me just say, I'd rather have a link to only a single OWASP Cheat Sheet than to have one with 2 or 3 links to it as references. Maybe it's just me being lazy or the rest of you really enjoy having a plethora of references, but I think the developer community is just frustrated by that. We're not writing references for a doctoral dissertation to impress faculty members, so more isn't better, unless your bound and determined to persist the myth that developers can never really understand AppSec because it's too complex and they just aren't smart enough. It that's your take though, then "welcome to the priesthood of the AppSec clerics". I for one call bullshit on that myth. Let us not forget that we are writing for the primary audience of developers. InfoSec / AppSec peeps are just a secondary audience.

Parting words

I know my mini-rant is not going to convince anyone, but I had to write it just to get it off my chest. You're all gonna do what you would had I not written the this reply. I want you all to know that I have the utmost respect for all of you and I don't think any of you have a giant ego or anything like than I, so it's not because of that. But I do think we need to collectively step bad and look at maybe do some planned organization of the cheat sheets such as splitting them into tracks or something. I just don't want the Cheat Sheet series to grow so complex that we need a cheet sheet to navigate the cheat sheets.

Just my $03.

[mackowski]

@kwwall this is very valuable, I think we can work on some solution to have some 'tracks' or somehow connect the cheatsheets together when they are related.
Before we do that I think we can add a reference/link to this new cheatsheet from old one and vice-versa. And We can add this somwhere in the beginning of the cheatsheet or with a H1 header to make it visible.