Using the CSRF page extension in CMS 6
EPiServer CMS 6 has a new page extension that add CSRF prevention on a Web form. I won’t go into detail of the CSRF exploit since Wikipedia has a good description. In short, someone uses a visitors browser to send a malicious request to another site were the user is already logged in to (or trusts in some way).
The countermeasure implemented in this page extension is a per-user cryptographically generated token stored in a cookie. A hidden field on the page is generated based on the user token and salted with information specific to that page. Whenever a post is made to the page we validate the tokens in the PreInit phase. There are no server-state involved except a per-site secret stored in the database used to protect the values from tampering (safe for load balancing).
This page extension called AntiForgeryValidation is completely transparent to the user as long as they have cookies enabled and hopefully to you as a developer as well.
But, you do want to test that it actually works after you implemented the code, the easiest way is to use a tool like Firecookie to manipulate the request. For example: Make a request to the page and store away the cookie __epiAntiForgeryToken_X, close the browser and go the page again, now edit the cookie and paste the old value before doing a submit to the page. The error you will get should be “This request has probably been tampered with. Close the browser and try again.”.
There are some limitations, it won’t work with output caching since we need the unique field on the page. Also, if you are doing some custom coding you need to post the hidden field “_epiAntiForgeryToken” as well or the page won’t validate. Also, the user must have cookies enabled.
This extension is used extensively on administrative interfaces in EPiServer CMS 6 that is based on Web forms. If you ever worked with ASP.NET MVC you will know that this feature exists in MVC as well and they use the same type of prevention scheme.
There are some alternative implementations of CSRF protection in ASP.NET Web forms like changing how ViewState is generated or by using Session State but we did not want to take an dependency on those features, you choose what scheme fits your requirements.
Le me know if you have any questions.