Is there a way to ensure ASP.NET MVC 4 forms are protected against CSRF by default?
For instance, is there a way to have AntiForgeryToken automatically applied to all forms in both views and controller actions?
Background on this question: Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper and Anatomy of a Cross-site Request Forgery Attack.
To add to osoviejo's excellent answer, the instructions below, from my recent blog post on CSRF, put his work together with the information in Phil's blog in one comprehensive answer.
ASP.NET/MVC provides a mechanism for this: you can add to to a collection of filters on the global FilterProviders object. This allows you to target some controllers and not others, adding the needed security feature.
First, we need to implement an IFilterProvider. Below, you can find Phil Haack's Conditional Filter Provider class. Begin by adding this class to your project.
public class ConditionalFilterProvider : IFilterProvider
{
private readonly
IEnumerable<Func<ControllerContext, ActionDescriptor, object>> _conditions;
public ConditionalFilterProvider(
IEnumerable<Func<ControllerContext, ActionDescriptor, object>> conditions)
{
_conditions = conditions;
}
public IEnumerable<Filter> GetFilters(
ControllerContext controllerContext,
ActionDescriptor actionDescriptor)
{
return from condition in _conditions
select condition(controllerContext, actionDescriptor) into filter
where filter != null
select new Filter(filter, FilterScope.Global, null);
}
}
Then, add code to Application_Start that adds a new ConditionalFilterProvider to the global FilterProviders collection that ensures that all POST controller methods will require the AntiForgeryToken.
IEnumerable<Func<ControllerContext, ActionDescriptor, object>> conditions =
new Func<ControllerContext, ActionDescriptor, object>[] {
// Ensure all POST actions are automatically
// decorated with the ValidateAntiForgeryTokenAttribute.
( c, a ) => string.Equals( c.HttpContext.Request.HttpMethod, "POST",
StringComparison.OrdinalIgnoreCase ) ?
new ValidateAntiForgeryTokenAttribute() : null
};
var provider = new ConditionalFilterProvider(conditions);
// This line adds the filter we created above
FilterProviders.Providers.Add(provider);
If you implement the two pieces of code above, your MVC application should require the AntiForgeryToken for every POST to the site. You can try it out on Phil Haack's CSRF example web site - once protected, the CSRF attack will throw System.Web.Mvc.HttpAntiForgeryException without having to add the [ValidateAntiForgeryToken] annotation. This rules out a whole host of "forgetful programmer" related vulnerabilities.
You can use a filter provider with a condition that the filter ValidateAntiForgeryTokenAttribute() be applied whenever HttpContext.Request.HttpMethod == "POST".
I essentially followed the generic approach described by Phil Haack, and added the appropriate condition:
// Ensure all POST actions are automatically decorated with the ValidateAntiForgeryTokenAttribute.
( c, a ) => string.Equals( c.HttpContext.Request.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase ) ?
new ValidateAntiForgeryTokenAttribute() : null
One way to do it would be to modify the T4 templates in ASP.NET MVC that create forms, to have them insert this code automatically:
<% using(Html.Form("UserProfile", "SubmitUpdate")) { %>
<%= Html.AntiForgeryToken() %>
<!-- rest of form goes here -->
<% } %>
And of course, you need the corresponding attribute on the controller method:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
It's really not that difficult to retrofit an application in this manner, unless it's unusually large. The last application I wrote in MVC would probably take me a couple of hours to retrofit.
I have used FXCop to write two code analysis rules one that require that a HttpMethod attribute is applied to all controller actions and a second that requires any action that has a HttpPost attribute must also have a RequiresAntiForgeryToken attribute.
This worked well for us. The rules are not particularly hard to write
