Any in-framework way to prevent Cross Site Request Forgery (CSRF) within ASP .NET 4.0 (not MVC)?

Is there any in-framework way to prevent Cross Site Request Forgery (CSRF) within ASP .NET 4.0 Web forms based websites (not MVC)? I do see the framework generate __EVENTVALIDATION and __VIEWSTATE hidden form fields and I've encrypted them via machineKey and viewStateEncryptionMode="Always" in my web.config. However, it's not clear if they can actually prevent CSRF attacks. I tested a cross posting (via PostBackUrl in the form's asp:Button) form where I modified the __VIEWSTATE, __EVENTVALIDATION and __PREVIOUSPAGE (extra for cross posts) hidden, encrypted form fields and the other sensitive form fields still reached my code-behind processing block. I was expecting the framework to detect the modified encrypted fields and throw up an error. FYI, I saved the aspx as an .html, changed those hidden form fields and 开发者_如何学JAVAre-used the form (now in .html) to simulate an attacker. So I could still post to my sensitive form/fields because (start speculation) .html files don't go through the ASP.NET processing engine? (/end speculation)

If no such in-framework mechanism exists, are there any code snippets for quick prototyping/usage? I can easily create a per-user unique identifier by hashing the user ID and even set a form hidden variable for that c# variable. But the ASP.NET 4.0 mechanics of

• Also setting that c# variable as a cookie

and

• Checking if the cookie value == form value on subsequent requests (for validity)

is unclear to me.

I don't know how to do it in the framework, but you can do it yourself easier than your post suggests.

You don't need to set the cookie value. Its just how the mvc framework does it as an optimization\ to allow the server to be stateless. All you need to do to pick some random ( to an attacker) value and add it as a hidden field in your form. When you get the data back, verify that that value is in the form. Don't just hash the userid, hash the userid and some secrete random value. That way the attacker can't compute the hidden value if she knows a user id.

Because the same origin policy prevents attacker.com from reading the markup for your site, they can't read the hidden value. Thus the CSRF post they make, while having your cookie ( and hence the view state), won't have that value.