Here’s a little checklist I put together for ASP .Net MVC. It includes the high level stuff to look at when reviewing a MVC application. In order to fully understand/consume the info it requires at least a basic understanding of MVC architecture which can be gained from any introduction document. Some of this stuff could be automated through something like FxCop.

Below is an outline of the different components of MVC that are important to look into when reviewing ASP .Net MVC applications. It’s also important to review the normal MVC spec’s to understand context, but here is a “security” minded checklist.

ViewData Dictionary

This is used to pass data from a Controller to the View. It’s extremely important to verify the ViewData on both the View and Controller. The ViewData is a dictionary for passing untyped data to the view. It’s important to make a recommendation that either data is encoded on the input or the output and try not to mix the two as you can get yourself in trouble. I think output encoding is easier to manage than input.
Look at the controller actions and the parameters they receive. If they are strings, verify on the output or input encoding occurs for the appropriate uses.  A grep to look for:

ViewData\[“”

ViewData.Model

The ViewData.Model is a method for passing TYPED objects back to the view. You can specify a ViewPage<T> where T can be a typed to the value of ViewData.Model. In your controller when you return a View you can pass the object to the page. Example would be return View(“Index”, objOfTypeT)

So it’s important to understand the type being used in this case as unencoded data can make it to the view from this object.

AntiForgeryToken Attribute

Any post which would require Anti-CSRF protections should include the AntiForgeryToken Attribute on the controller Action where the post submits to. There is also a requirement on the View side of things to ensure that the AntiForgeryToken is actually used. Make sure that Html.AntiForgeryToken() method is being called within the form definition on the view.

Public Methods in the Controllers

Any public methods contained in the controller are accessible via crafted URLs. Verify there are no unintended consequences from public methods, also validate that authZ occurs on appropriate methods.

Direct browsing View pages

The View directory for the MVC application contains a web.config for blocking access to view pages among other view wide configurations. It’s important to note that by default .aspx pages are blocked, however if there is a custom extension being used you will to ensure they are explicitly blocked via config. Below are the relevant keys

IIS 6
<add path="*.aspx" verb="*" type="System.Web.HttpNotFoundHandler"/>

IIS 7
<add name="BlockViewHandler" path="*.aspx" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>

Controller Action Parameters

Action parameters can be complex types. For example you could have Action with a method signature like below.

[AcceptVerbs("POST")]
public ActionResult Edit(Product product)

In this case Product could have some public properties associated with it like {Name, Id, etc.}. If Price was meant to be set later by the db after a look occurred on the product id you could end up in trouble depending on the logic.

The root problem here is if the complex type exposes a property that was not supposed to be set by the client you could inadvertently end up with a tainted object. Also it introduces a place where unencoded data could make it to the view depending on how the object is used.
Here is a link that explains it better and more in detail.
http://www.codethinked.com/post/2009/01/08/ASPNET-MVC-Think-Before-You-Bind.aspx