ViewStateUserKey Doesn’t Prevent Cross-Site Request Forgery
"ViewStateUserKey is not a completely effective mitigation against Cross-Site Request Forgery. It doesn't work for non post-backs (I.e. GET requests), and it doesn't work if the ViewState MAC is turned off.
In several different places, we see a piece of advice repeated - use the ViewStateUserKey property to prevent One-Click Attacks. Often, this piece of advice is accompanied by the following code:
void Page_Init(object sender, EventArgs e)
{
ViewStateUserKey = Session.SessionID;
}
What exactly does this code do? To understand it, we first need to look at the ViewState mechanism itself. The ViewState is an ASP.NET mechanism used to persist the value of web controls between post-backs. This allows a lot of the drag and drop, UI-driven ASP.NET architecture to function "auto-magically" by serializing and de-serializing data automatically on the fly.
The ViewState is encoded and stored as a hidden field. This introduces security issues, because the value is under the control of the client. There may be a value stored in a field that you do not want someone to see and modify, like an admin-only control with the visible property set to false."
Read more of this article:
http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx
First a couple of notices: 1)GET should NOT be used for modifying data server-side, according to W3C HTTP protocol specification, so only POST should be protected against CSRF. 2) In 10 years, I still haven't seen an application that has view state disabled, so I think this is a remote case.
You explained well how View State works, besides that, .NET frameworks calculates a Hash/MAC to ensure view state is not modified when sent back to the server, this MAC is stored in another hidden field. To create this MAC, Machine key and ViewStateUserKey are both used as seed to the hash function. So by changing the ViewStateUserKey value with the session ID (as suggested by all these sites), it is impossible to replay HTTP requests to the server as the view state MAC is unique to each user session, even if the information in view state is the same, MAC validation will fail as hashes will not match.
So unless there is a Cross Site Scripting (XSS) vulnerability on the web site and the attacker can get the view state and view state mac, it is not possible to replay that request on the users behalf which is exactly the problem with CSRF.
Hope this helps to clarify how this suggested method works.
Posted by: Juan C Calderon | Jul 5, 2014 3:57:06 PM