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.