3

I'm a relatively new developer working on a C# MVC app, and serving different views to different people depending on what fields they should be able to see. That is, user 1 might see (and be able to enter data into) fields A, B, and C, whereas user 2 may only see field A.

My plan at the moment is to post the form back to a single action in my controller, but I was trying to figure out whether or not I need to protect against the possibility of user 1 modifying the form when (s)he gets it, adding fields B and C in the browser, and then sending it back to the server, in an effort to set values in the database that (s)he shouldn't have access to.

I'm told by someone else in the area that the AntiForgeryToken should protect against this type of attack, but my research implies that it only protects against a cross-site forgery attack, and I don't think this falls into that category. My question is this: Does the AntiForgeryToken protect against this situation? Or do I need to continue with the idea of "don't trust what the user sends you" and explicitly ignore those fields that the user doesn't have rights to use?

MDD
  • 147
  • 9
  • 2
    You are right. Antiforgery token protects from the CSRF. The issue you talk about is a regular RF on the same domain. The only way to protect yourself is double check every POSTed value whether or not it falls in a range of valid values. – Wiktor Zychla Nov 20 '15 at 22:25
  • What your referring to is over posting and no, the anti forgery token does not prevent this. – Sacrilege Nov 20 '15 at 22:27

2 Answers2

2

You are absolutely right that this is a problem. All the anti-forgery token does is to ensure the form is generated by your application, as opposed to being handcrafted. However, that doesn't mean it can't be tampered with afterwards.

As an example, say you have 2 users, who both have accounts with your application: GoodUser and NaughtyUser. They both use your application to request a specific form, that allows them to do something on the site (e.g. edit an auction). The difference between them is that GoodUser is only interested in editing an auction, but, as the 2 users are in direct competition with each other, NaughtyUser wants to sabotage GoodUser's auction.

To do that, NaughyUser decides to open a form to edit one of his own auctions. At this point, he has received a valid anti-forgery token in the form. So now NaughtyUser modifies the data on the form, the idea being to intentionally edit GoodUser's auction, and POSTs it to the server. The anti-forgery token on its own will absolutely not protect against that, because the token itself was generated via a legitimate source.

This is a different kind of attack, and something you definitely should be protecting against on the server-side.

John H
  • 14,422
  • 4
  • 41
  • 74
1

It is quit simple. In order to protect our server from illegal requests we allow to submit forms that were made only by our server. It means that once ASP.NET server executes action method and prepare HTML for the client, it would sign your form with a encrypted token. When form submits, this server-generated token will be sent with form's data, and if you mark your action with validateantiforgerytoken attribute, then server will check form for this unique token. If it exists and token generated on this server, validation will be passed.

Vnuuk
  • 6,177
  • 12
  • 40
  • 53
  • Anti forgery token is not about signing anything. The term "signing" is reserved for cryptohraphic operations involving crypto algorithms. In contrast, the aft works by combining a random token in a cookie and in a hidden form variable, something one cannot forge cross-site. – Wiktor Zychla Nov 21 '15 at 12:19
  • This answer implies to me that my question was unclear, since it doesn't seem to answer my question. I have adjusted the title to more accurately reflect my actual question, which is buried at the end of my text. – MDD Nov 23 '15 at 17:47