0

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)

  • Currrently, 80% of the browsers support SameSite: 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 at 14:45
  • So, for browsers that supports it it is absolutely secure (not need for tokens). Correct? – Michael Jan 13 at 15:11
  • 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 detailed answer to a similar question. – Stradivari Jan 13 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 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. – waymobetta Jan 17 at 19:53
2
+50

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.

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.