19

During a security assessment I noticed that Firefox automatically set the SameSite value of a session cookie to Lax. According to the Mozilla specs, this is the case for 'modern browsers'.

The SameSite attribute set to Lax seems to protect against CSRF (every cross-origin request that's doesn't use GET). Obviously, outdated browser would still be vulnerable.

Would you still bother developers with implementing CSRF protection, if session cookies are protected by default in modern browsers? It depends on your security/business philosophy, and the type of application, whether it's worth the effort. I'm interested in your opinion on the matter. Obviously, in the best case one would implement classic CSRF protection everywhere, but it keeps getting harder to sell the implementation efforts as a business case to development teams.

Improve this question
3
  • 3
    The real take away below is that developers shouldn't be implementing CSRF protection, they should use a framework that does this for them. If your developers are implementing something as low-level as CSRF protection, I'd worry about what else they're not doing, that a good framework would take care of.
    – user229044
    Jul 9, 2020 at 14:49
  • 1
    Indeed, but the crux is that many companies have monsters of legacy systems that don't use a neat framework that offers CSRF protection. In a 10-year old system with tens of thousands LoC, proper system-wide implementations can be a real pain.
    – Beurtschipper
    Jul 9, 2020 at 15:16
  • 2
    Be aware that SameSite only applies to cross-site requests; it is powerless against cross-origin, same-site attacks. If you only rely on SameSite to protect your users against such attacks, all an attacker needs to successfully mount one is find an XSS on or take over one of your subdomains. See jub0bs.com/posts/2021-01-29-great-samesite-confusion
    – jub0bs
    Feb 1, 2021 at 15:01

5 Answers 5

Reset to default
9

The current answer shows that we currently should not. But at what point in the future can we start to rely on this?

Comparing the data from caniuse and the MDN support tables. You can observe that there is no browser that exists which supports TLS 1.3 and does not support SameSite cookies.

Browser SameSite TLS 1.3
Edge 16 79
Firefox 60 63
Chrome 51 70
Safari 12 + Mojave 12.1 + Mojave
Opera 39 57
iOS 12 12.2

Going from this table, a very convenient answer (since we can't feature test SameSite cookies effectively) is:

  • When you disable TLS 1.2 and lower on your web server.
  • If you do not allow user generated forms on the same domain (including all subdomains)

As soon as it is no longer possible to connect with TLS 1.2. All browsers visiting your website will support SameSite cookies and enforce the settings.

To re-iterate the settings:

SameSite=Strict

  • Perfect protection for all requests coming from different domains.
  • No protection from subdomains.

pages.github.com can still perform a CSRF against github.com. If you intend to allow user-hosted content you would need to keep using coventional CSRF tokens or use an separate domain like github.io for untrusted content.

SameSite=Lax

  • Depend upon HTTP verbs for protection. CSRF protection is only as good as you ensuring sensitive operations never respond to GET requests.
  • No protection from subdomains.

pages.github.com can still perform a CSRF against github.com. If you intend to allow user-hosted content you would need to keep using conventional CSRF tokens or use an separate domain like github.io for untrusted content.

SameSite=None

You are doomed. Keep using conventional CSRF tokens.

Improve this answer
5
  • 1
    I think you should expand on "Subdomains count as internal.". The ramifications may not be clear to the casual reader.
    – jub0bs
    May 26, 2021 at 6:42
  • 2
    I have expanded on that with more detail and examples.
    – anthonyryan1
    May 27, 2021 at 15:27
  • Great. Thanks :)
    – jub0bs
    May 27, 2021 at 15:59
  • Why does TLS version matter?
    – Jehong Ahn
    May 15 at 16:19
  • The TLS version does not matter, we're using that in a similar way to version sniffing. Once older TLS versions are gone, the browsers which do not support SameSite will no longer be able to connect. Unfortunately we cannot feature test whether or not a browser supports SameSite cookies.
    – anthonyryan1
    May 16 at 17:05
10

You still need "traditional" CSRF-protection. Maybe this will change in the years to come, but as of writing the SameSite attribute should be viewed more as defense in depth than your one and only line of defence. This is for a few reasons:

  • According to caniuse.com, there is currently only browser support for 85% or 92% (if you count partial support) of global users. For instance IE 11 on Windows 8 (still used in many offices around the world) doesn't support it, and neither does the UC Browser on Android.
  • Relying on browsers to auto upgrade to Lax is even worse, since not all supporting browsers do this. I don't have any numbers, though. But at the very least, you need to explicitly set the flag.
  • Do you really trust all current and future developers of your application to never change server state on a GET request? I wouldn't do so - I would not even trust myself. If you want to rely on SameSite, set it to Strict.
  • If you do not trust your subdomains, SameSite will not help you. See this great article by jub0bs.
  • As I write in this answer (second bullet point) there are some cases where you will always need a traditional CSRF-defence.

TL;DR: Just the SameSite flag is not enough to protect your users from CSRF.

Improve this answer
1
3

SameSite=Lax means NO CSRF protection for GET requests.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Cookies are allowed to be sent with top-level navigations and will be sent along with GET request initiated by third party website. This is the default value in modern browsers.

In an ideal case, that may be sufficient CSRF protection. But the real world is far from ideal. Web APIs with non-safe GET requests are far from rare (a GET request that changes a server-state, although it shouldn't, according to the HTTP specifications).

Also, not all browsers correctly implement the samesite flag (yet): https://caniuse.com/#feat=same-site-cookie-attribute

And some older never will.

It's safer to implement additional explicit CSRF protection like synchronizer token pattern.

Improve this answer
1
  • And all SameSite settings are vulnerable to any stored XSS vulnerability on your whole domain including all subdomains. I'd definitely recommend implementing CSRF token protection for all unsafe operations.
    – Mikko Rantalainen
    Aug 25, 2021 at 12:11
3

With samesite being supported in all major browsers, it's a borderline issue.

  • As a developer, I typically use either a framework with built-in CSRF protection (e.g. Spring Security) or Ajax endpoints. Implementing CSRF protection is no hassle, and I continue to use it now we have samesite cookies.

  • As a pen tester, I'd raise lack of CSRF protection on POST requests as low-risk or informational. If a GET request allowed an action, I'd flag at a higher risk level, depending on what actions were vulnerable.

Improve this answer
0

During a security assessment I noticed that Firefox automatically set the SameSite value of a session cookie to Lax. According to the Mozilla specs, this is the case for 'modern browsers'.

This is kind-of true. Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. It's still better to explicitly mark your cookies as SameSite.

Would you still bother developers with implementing CSRF protection, if session cookies are protected by default in modern browsers?

No. Same-site cookies alone are sufficient to protect against CSRF. If the application's framework supports CSRF tokens I would enable them, but if it takes much effort I wouldn't bother. I consider same-site cookies a sufficient solution against CSRF.

I would advise to have both a SameSite=Lax cookie and a SameSite=Strict cookie. This way, you can check whether the request is strictly same-site before performing important changes.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.