Using MVC3’s AntiForgeryToken in HTTP GET to avoid Javascript CSRF vulnerability

The Asp.net MVC AntiForgeryToken won’t work through HTTP GET, because it relies on cookies which rely on HTTP POST (it uses the “Double Submit Cookies” technique described in the OWASP XSRF Prevention Cheat Sheet). You can also additionally protect the cookies sent to the client by setting the as httponly, so they cannot be spoofed via a script.

In this document you can find various techniques that can be used to prevent XSRF. It seems the you described would fall into the Approach 1. But we have a problem on how to retrieve the session on the server when using Ajax HTTP GET request since the cookies are not sent with the request. So you would also have to add a session identifier to you action’s URL (aka. cookieless sessions, which are easier to hijack). So in order to perform an attack the attacker would only need to know the correct URL to perform the GET request.

Perhaps a good solution would be to store the session data using some key from the users SSL certificate (for example the certs thumb-print). This way only the owner of the SSL certificate could access his session. This way you don’t need to use cookies and you don’t need to send session identifiers via query string parameters.

Anyway, you will need to roll out your own XSRF protection if you don’t want to use HTTP POST in Asp.net MVC.

Leave a Comment