9

According to learn.microsoft.com ASP.NET core implements the Synchronizer Token Pattern to mitigate CSRF.

The Anti request forgery mechanism has many drawbacks impacting users:

ex 1: login page opened in 2 tabs

  • Open the login page in two different tabs
  • User A logs from Tab 1 (No issues)
  • Without refreshing the Tab 2, user B tries to log in.

=> Produces a 400 page with AntiforgeryValidationException

reference 1, reference 2

ex 2: a form opened in 2 tabs (from the same link in a mail)

  • Create a new Asp.Net Core MVC website from template (VS 2019)
  • Create a new page which has a simple form which is validated with [ValidateAntiForgeryToken] on post.
  • Email yourself a link to that page (I've used Gmail & Mailtrap)
  • Open the link in two tabs by clicking on it normally
  • Submit both forms in any order

=> The form which was opened FIRST produces a 400 error

reference

It looks like SameSite=strict is an effective security measure against CSRF attacks

According to this article and this draft RFC, SameSite cookie seems an effective and robust security measure against CSRF attacks. ASP.NET Core 2.2's authentication cookie are configured with SameSite=strict. If my understanding is correct, authentication cookie are only sent to the server in a same-site navigation situation.

In my use case I trust the sub domains.

So if I can guarantee that my users are using a browser supporting the SameSite policy, is it safe to disable the anti CSRF mechanism of my ASP.NET Core application?

Community
  • 1
  • 1
Yanal-Yves Fargialla
  • 1,257
  • 15
  • 16
  • 1
    https://github.com/aspnet/AspNetCore.Docs/issues/14251#issuecomment-544138663 makes me feel that it's safe to use samesite policy in a situation where I can guarantee that my user' browers supports SameSite policy. – Yanal-Yves Fargialla Feb 19 '20 at 13:40
  • Late comment, but FWIW: the answer to your question largely depends on how you define your attack surface. CSRF tokens and `SameSite` do not defend your users equally against all kinds of threats. In particular, `SameSite` is powerless against a cross-origin attack mounted from a subdomain of the target origin. Therefore, if you can't trust your subdomains, `SameSite` won't be enough to protect your users against cross-origin abuse. I've written about this elsewhere: b0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Apr 21 '21 at 06:19
  • 1
    @jub0bs, thank you for your comment. I'm getting a 404 when trying to access the link you provided. Would you mind updating the link in your comment please ? In my use case I trust the subdomain. I'll update my question to add this information. – Yanal-Yves Fargialla Apr 22 '21 at 13:00
  • Sorry, I only pasted the end of the link. Here is the correct one: https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ – jub0bs Apr 22 '21 at 14:03
  • See also https://stackoverflow.com/a/74413988/16462950 – Heiko Theißen May 26 '23 at 15:25

0 Answers0