21

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
Beurtschipper
  • 693
  • 4
  • 10
  • 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 09 '20 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 09 '20 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 https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Feb 01 '21 at 15:01

5 Answers5

11

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.

anthonyryan1
  • 388
  • 2
  • 7
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.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • 6
    Don't forget to mention cross-origin, _same-site_ attacks against which `SameSite` is powerless. See https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Feb 01 '21 at 15:05
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.

Community
  • 1
Martin Fürholz
  • 795
  • 9
  • 21
  • 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 '21 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.

paj28
  • 32,736
  • 8
  • 92
  • 130
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.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • 1
    Careful. The relevant Internet Draft itself recommends `SameSite` only [as a measure of defense in depth](https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-5.1). `SameSite` is not a drop-in replacement for anti-CSRF tokens; in particular, `SameSite` is [powerless against cross-origin, _same-site_ attacks](https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/). – jub0bs Feb 04 '21 at 18:10