locked
ASP.NET MVC AntiForgeryToken not bound to Session and does not have integrity check RRS feed

  • Question

  • User-1469803742 posted

    I have been developing a web application where security is one of the highest priorities. We have been using the MVC built in AntiForgeryToken to prevent CSRF attacks. So far we have believed that it is a solid defense against said exploits but recently it has been brought to our knowledge that there are some issues or rather imperfections with the way the token is handled.

    First off the token is only validated against the value in the cookie that is provided in the same request as the value from then hidden input in the submitted form. This means that if the attacker is able to forge both the cookie and the hidden input value then the CSRF attack will succeed. Is there a reason why the token is not stored in the session as well? Would it not provide even better security? Now it is possible to use the tokens from a given user session in other sessions of the same user.

    Secondly there is no integrity check for the token (e.g. HMAC). This means that it is at least in theory possible to corrupt the token so that it is still valid. If there would be an integrity check then modified tokens would be automatically rejected. Again is there a reason why this has not been implemented to the AntiForgeryToken?

    I am in a situation where if I want to make our application more secure I have to start writing my own implementation of the AntiForgeryToken. Before doing that I thought it would be worth the while to ask if anyone has ideas for how the AntiForgeryToken could be extended/improved so that I would not have to write my own implementation from scratch? Or if anyone knows reasons why the MVC AntiForgeryToken lacks these security features I would be interested to know about them also.

    Thursday, November 21, 2013 5:53 PM

Answers

  • User1779161005 posted

    Yes they're doing an integreity check.

    And the value in the token itself is being produced with a key from the server. So, there is something on the server that helps verify the token (it's the <machineKey>).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 22, 2013 8:49 AM

All replies

  • User1779161005 posted

    Session state is, IMO, generally bad. I can see how Microsoft wouldn't want to impose that upon people.

    The tokens are being protected with the MachineKey APIs, so they are being signed (as well as encrypted).

    Thursday, November 21, 2013 6:33 PM
  • User-1469803742 posted

    You might be right about the session state not being the best place to store the token but the idea is that if it was stored somewhere on the server (database, session, cache, etc.) it would provide more security because then it would not be possible to get around the validation by forging both the cookie and the form input field. I guess one way to go around this is to create an additional custom token and then use IAntiForgeryAdditionalDataProvider to validate it on the server?

    I'm a bit confused about what you mean by being signed. Do you mean that the AntiForgeryToken actually has an integrity check? What I'm worried about here is that is it theoretically possible (although very difficult) to make changes to the token and have the server accept it as a valid token?

    I'm sorry if this is all a bit nitpicky but the reason why I'm being so thorough is that our wep app is being audited by an security company that claims to have found these CSRF vulnerabilities and I'm trying to come up with a proper answer for them.

    Friday, November 22, 2013 2:36 AM
  • User1779161005 posted

    Yes they're doing an integreity check.

    And the value in the token itself is being produced with a key from the server. So, there is something on the server that helps verify the token (it's the <machineKey>).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 22, 2013 8:49 AM
  • User-1469803742 posted

    Thank you very much for taking the time to answer my question. Machine key as a concept is not very familiar to me but it seems to be exactly what I was looking for.

    Monday, November 25, 2013 4:21 PM