ViewStateUserKey stored as a HttpCookie is secure or not?

Question

This link (http://software-security.sans.org/developer-how-to/developer-guide-csrf) tells me that starting with Visual Studio 2012, Microsoft adds built-in Cross-Site Request Forgery (CSRF) protection to new web forms application projects. Add a new ASP .NET Web Forms Application to your solution and view the Site.Master code behind page. This solution will apply CSRF protection to all content pages that inherit from the Site.Master page.

The auto-generated code by Visual Studio 2012 generates a random GUID and then stores the GUID into a HttpCookie, which is then used by different web pages. On each page, this GUID is assigned to the Page.ViewStateUserKey so that ViewStateUserKey can protect CSRF attacks. The condition is the app must use SSL.

Why does the cookie not need encryption? I know that the app needs to have SSL. But the GUID stored a plain text in the cookie is not good security, is it?

Answer 1

The cookie does not need encryption (aside from SSL) because it only needs to be kept secret from third-parties who might be trying to attack the user with CSRF. Because browsers will not send cookies to sites outside of the domain that set the cookie, a supplying of the cookie with the request is all the server needs to verify that it is the user making the request and not a third party. Since third parties can't set cookies for domains other than their own, and cookies aren't submitted to them outside their domain, there is no way that the user will submit the required cookie if the user is the victim of a CSRF attack.

This question may help explain this in a little more detail, if you are still interested: How is using Synchronizer Token Pattern to prevent CSRF safe?

Answer 2

This is a pretty standard way to mitigate against CSRF attacks. You set a value in a cookie and confirm that value through the POST data. The reasoning behind this is that while it's easy to craft a request to be POSTed to any server with any values, it's not as easy to obtain any cookies. The same origin policy will prevent you from doing this through JavaScript unless you're on the same domain as the page you're sending to. This would probably only be the case in an attack if your cookies are not set with HttpOnly and there's an XSS vulnerability on the target website, in which case all bets are off anyway. Similarly, the same origin policy will prevent you from loading up the target form in an iframe and accessing the hidden field through JavaScript.

The security value here comes from the inability to obtain (or set) the secret cookie value on another domain, which is automatically sent with the user's requests to that domain. Likewise, the security of your entire application is probably very dependent on this. Without these same origin protections, your cookies would be easily exposed all over, and your sessions would be easily hijack-able.

A common way to do the CSRF protection is actually to use the session ID as the CSRF token. It's a random value stored in a cookie, so it works just fine. The problem with doing this in ASP.NET, I believe, is that if you aren't using sessions, or if you haven't set any data in session yet (e.g., before the user logs in), the session ID will keep changing, which is no good. A random GUID works just the same.

SSL is largely unrelated here. If an attacker has access to your cookies, he has everything he needs to impersonate you anyway, eliminating the need for CSRF. It's worth noting that cookies passed over HTTPS are encrypted, as they're part of the HTTP headers.