2

Recently most browser have added support to the SameSite cookie attribute to prevent CSRF attacks: https://www.owasp.org/index.php/SameSite

Question if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks? https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Synchronizer_Token_Pattern

Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern?

I do know that SameSite options are strict and lax and probably we will use the lax value.

Added

Is the CSRF attack possible if we use only SameSite setting (without Synchronizer Token Pattern) in a browser that supports the setting (https://caniuse.com/#search=Samesite)?

What is a possible attack scenario?

(the question is not related to the XSS attack, only to the CSRF attack)

Michael
  • 1,457
  • 1
  • 18
  • 36
  • Currrently, 80% of the browsers support SameSite: https://caniuse.com/#search=Samesite. When 100% support it, you could omit the tokens. Until then, I'd stick to the token since it is supposed to work with any client. – eckes Jan 13 '19 at 14:45
  • So, for browsers that supports it it is absolutely secure (not need for tokens). Correct? – Michael Jan 13 '19 at 15:11
  • 1
    You can still be vulnerable against On-Site Request Forgery attacks if your rely only on the SameSite cookie attribute. Have a look at [this](https://security.stackexchange.com/a/121986/92297) detailed answer to a similar question. – Stradivari Jan 13 '19 at 16:25
  • In the answer I can find the following "The same old caveats as for old fashioned CSRF protections still apply". What attack may be applied if we use only SameSite setting? – Michael Jan 17 '19 at 14:53
  • I believe the "same old caveats..." attack that was referred to would be XSS. The author was saying that despite setting a SameSite cookie attribute, if an XSS vulnerability exists then CSRF protection would not matter because any action done would be on behalf of the authenticated user, removing the need for a CSRF attack altogether. – jonroethke Jan 17 '19 at 19:53

2 Answers2

2

if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks?

No! However, you absolutely shouldn't be using GET like request methods for state changing actions.

Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern?

Yes! Since it omits sending cookies (flagged SameSite) to requests originating from 3rd domain, Cross-Site requests cannot make authenticated requests. This, thus, prevents CSRF. However, SameSite cookies don't block all kinds of GET requests. Link prerender requests, for example, are some exceptions and probably will not be added to the list. Therefore, it's very crucial not to use GET requests for state changing actions.

Is the CSRF attack possible if we use only SameSite setting (without Synchronizer Token Pattern) in a browser that supports the setting

Short answer: No
It's possible to overwrite cookies. This, however, doesn't make it vulnerable to CSRF. To overwrite a cookie, an attacker must supply a value. In this case, if s/he already knows the cookie value, s/he already has access to victim's account. However, On-Site Request Forgery (as mentioned in comment) is always an exception.

What is a possible attack scenario?

There aren't any unless combined with ither vulnerabilities.

Edit:
Plugin initiated requests (Flash, PDF, etc.) might not act as you expect. They may or may not SameSite cookies. Therefore, atm, use tokens along with SameSite cookies.

1lastBr3ath
  • 909
  • 6
  • 13
  • Careful: `SameSite` is powerless against cross-origin, _same-site_ requests. See https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Feb 04 '21 at 17:46
0

New answer to an old question, but please bear with me.

Regardless of the type of anti-CSRF-token implementation you're considering (whether if be the synchronizer token pattern or another), be aware that the SameSite cookie attribute is not a drop-in replacement for anti-CSRF tokens; SameSite and anti-CSRF tokens do not protect against the same attack vectors equally.

There is a reason why the cookie attribute is named "SameSite" and not "SameOrigin". Conflating site and origin is misleading and can lull you into a false sense of security about the level of protection that SameSite provides against cross-origin attacks.

In particular, contrary to anti-CSRF tokens, SameSite cannot protect your users against cross-origin, same-site attacks. That's right: a request (and, therefore, an attack) can be cross-origin but same-site; see this web.dev post.

If you rely on SameSite exclusively, you better scrutinise the security level of all your subdomains: a single subdomain takeover or an instance of XSS (or, perhaps, of HTML injection) on one subdomain of the same site could be enough to bypass the protection that SameSite provides. (I recently wrote a blogpost about this.)

jub0bs
  • 283
  • 2
  • 11