1

In this post, there is a paragraph that mentions a scenario where there is no need to validate anti-forgery token in login page:

When is it OK to leave off the anti-forgery token? In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

I understand how a CSRF attack works but I am quite lost at this paragraph unfortunately. It says:

  • If the target is a URL
  • If accessing that URL has no side effects

Is there a target that is not URL? and what is an example for a "side effect"?

I have an ASP.NET MVC application that is hosted at a URL such as subdomain.domain.com. My users receive these errors:

“The provided anti-forgery token was meant for a different claims-based user than the current user.”

“The anti-forgery cookie token and form field token do not match.”

“The provided anti-forgery token was meant for user "", but the current user is > "XYZ".”

In other words, my question is that what are the scenarios in which it is okay not to use anti-forgery token in login page?

Community
  • 1
Ned
  • 111
  • 1
  • 2

3 Answers3

2

Visiting a URL can cause a side effect. For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy). That's a side effect. Or, it might log me out, or log me in, or update some settings. Those are side effects, too.

In general, a operation has a side effect if it changes some (persistent) state on the server, or has some persistent observable effect on the world.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • Just for anyone reading, "side effect" can be thought of as non-idempotency. – David Klempfner Jan 18 '21 at 09:21
  • 1
    @DavidKlempfner, I think they're closely related, but I don't think it's exactly identical. Consider a missile silo that has exactly one missile in it. The command "Launch all missiles!" is an idempotent command (doing it twice has the same effect as doing it once, as after you've done it once there are no more missiles remaining); but the command does have a side effect. You need an anti-forgery token (CSRF token) for that kind of command, too. – D.W. Jan 18 '21 at 20:07
  • Good point, didn't think of that. – David Klempfner Jan 19 '21 at 01:23
1

My understanding is the real issue is cookies that store the auth credentials because the browser automatically sends it to the URL. If you don't use cookies and don't have some script that always sends auth data on request, you don't need the anti-forgery token. It doesn't make sense to ever use it if you think about it. If you just use a JWT token or some other token (a unique string), it is the same thing as sending an anti-forgery token because ultimately that is what the anti-forgery token is. You should also use SSL or TLS.

General rule: don't use cookies. They have been proven time and time again to be a bad design pattern.

kevin
  • 111
  • 1
  • Ok, but your http(s) server gets the requests, from multiple clients, simultaneously. Their IP can change between the requests, and multiple clients can come from the same IP. How do you identify on a secure way, to which client/user an actually given request belongs? – peterh Feb 20 '20 at 11:13
  • Your question is about HTTPS and if it is secure. HTTPS protects from a man in the middle attack by protecting the connection. That is why it is required for protecting the token (to prevent others from knowing what your token is). – kevin Feb 21 '20 at 16:04
0

CSRF protection is not required when the action performed by the cross site request itself is trivial. But it is ideal to have such a protection for any action which has a persistent aftereffect in the applications context.

For example:

A file upload for configuration files would require an anti-CSRF token where as a simple search query which will only display the information would not (if your application's CORS settings are set right. )

In case of login pages, it wouldn't be required in general unless a failed login action itself would create a persistent change in application's context.

hax
  • 3,891
  • 1
  • 16
  • 34
  • 3
    You're neglecting the possibility of a successful login action, using the attacker's credentials (ie [login CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests)). – AndrolGenhald Mar 24 '19 at 00:07
  • @AndrolGenhald Even in that case, nothing other than the login action itself would be possible if the application itself is protected against CSRF in post-login actions. – hax Mar 24 '19 at 00:44
  • Doesn't matter, it's still a vulnerability. I go to definitelynotmalicious.com and it uses login csrf to log me in to victimstore.com with an attacker's account; later I go to victimstore.com and buy something using my credit card, and since I expect to buy more stuff in the future I have it save my shipping address and credit card to "my" account. Attacker now has my credit card number and shipping address. – AndrolGenhald Mar 24 '19 at 00:54
  • A bit far fetched but a valid case I agree. If the application you test is if that kind, then it makes sense. – hax Mar 24 '19 at 01:08