0

I believe after reading a few other questions that my understanding of Anti Forgery Tokens is incorrect.

I have a few controller post actions that take the same model but perform different actions based on certain logic.

By editing the form's action in Chrome's developer tools, I was able to do something unexpected in my code.

I am guessing I need to use the ActionName("action") data annotation for what I need to do now, however, I am still curious as to what protection the token gives? Is it purely to stop external sites posting to forms but no actual protection within an app?

Dev X
  • 89
  • 9
  • 1
    Yeah, CSRF is a concept that is unrelated to the underlying technology you use to implement it. Different frameworks may apply different strategies in how exactly the tokens are transferred but the basic idea is the same. – poke Jun 17 '19 at 12:59
  • @Dev X, This article explains about anti-forgery token in FormTagHelper in ASP.NET Core. I hope it will help you http://blog.vivensas.com/cross-site-request-forgery-in-asp-net-core-formtaghelper/ – Golda Sep 03 '19 at 08:23

1 Answers1

2

Antiforgery tokens are to prevent CSRF (cross-site request forgery) attacks. That is all. Imagine a scenario where a malicious actor sets up a Facebook login page clone. It looks just like the Facebook login page, and through some means, they manage to funnel users there (phishing emails, etc.). The user puts in their username and password and hits submit. The form action is set to go to the actual Facebook login page, so as far as the user is ever concerned, they logged in and are now at Facebook as they expected. However, the malicious actor was able to access their credentials when they typed them in, and can now go forth to steal their Facebook account.

The antiforgery token prevents this by putting a token on page that must match with the token generated server-side, after posting. A third-party has no way to generate a token that will match on their own, so now any attempt to carry out something like the above will instantly fail. That is it, in a nutshell.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • 3
    Your example is a bit weird for CSRF. If you have a phishing form and get users to enter their credentials, you do not need to have that form action point to the actual login page. You just get the credentials directly. – CSRF is more for cases, where you do something and that something actually posts to a potentially harmful endpoint on some other site where you have credentials in your browser. E.g. if the “Add Comment” button to the right would POST to the Facebook endpoint that publishes a post on my Facebook wall. – poke Jun 17 '19 at 12:58
  • Perhaps. I was trying to keep it pretty simple though. Yes, while it's true that the credentials would still be exposed either way, the inability to actually make the login happen would at least signal to the user that something was not right, and perhaps prompt them to realize the mistake and change their password or something. Whereas, if you could make it seamless, then most users would never notice. – Chris Pratt Jun 17 '19 at 13:04