Last post Nov 25, 2013 04:21 PM by mattipet
Nov 21, 2013 05:53 PM|mattipet|LINK
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.
Nov 21, 2013 06:33 PM|BrockAllen|LINK
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).
Nov 22, 2013 02:36 AM|mattipet|LINK
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.
Nov 22, 2013 08:49 AM|BrockAllen|LINK
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>).
Nov 25, 2013 04:21 PM|mattipet|LINK
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.