5

If the default value for the samesite directive in the Set-Cookie header is lax, then surely the only way for a CSRF attack to work, is if the website's developer, for some reason, puts a less restrictive value for samesite.

Or, is there some other way a CSRF attack could work?

1

1 Answer 1

8

Are CSRF attacks a thing of the past?

No

First of all, there are legitimate reasons to use SameSite=none. One obvious example is any site where the back-end serves multiple front ends via CORS, but it can also happen that you need something hosted on a public domain that's different from the back-end domain and it would be difficult or expensive to re-work it.

Next, there's the subdomains issue. SameSite is not the same as same origin, and in particular treats any immediate subdomain of any "public suffix", and all of its subdomains to any number of levels, as the same site. This helps somewhat with avoiding the need to disable samesite (e.g. site.com, www.site.com, app.site.com, sandbox.environment.app.site.com, and api.site.com are all considered the same site), but it also runs into problems if not all the content on your "site" is equally trustworthy (as often it is not). Even disregarding situations where you're expressly vending subdomains to users (e.g. Tumblr), it's fairly common to have situations where e.g. your support.site.com is a third-party ticketing service (e.g. Zendesk) and probably shouldn't be allowed to attempt CSRF attacks against your actual webapp.

Then there's the sites that handle authentication, or at least authorization, without cookies. They might do it by source IP address, by having access to a restricted network, by HTTP Basic or Digest auth, by Kerberos / Active Directory auth, by TLS mutual authentication (TLS client certificates, which often send automatically just like cookies), and probably more than I'm forgetting. The important point is that all of these are at risk from CSRF, and SameSite - being specific to cookies - offers no protection.

Finally, there's legacy browsers. SameSite never came to all browsers, much less the change from default none to default lax; that's only a few years old. While this is much less of a problem in the developed world, there are place in the world where people still run XP, and even Internet Explorer on it. There are places where people are still running very old versions of Android, with its legacy browser. There are devices with embedded Windows systems that still use legacy browsers. Should people be browsing the web with such outdated software? No, of course not. But depending on the target market for your software, you might have some users of such legacy browsers, and your site security measures should take that into consideration.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .