I’ve been working on code auditing for a project that makes use of the latest ASP.NET MVC api. Turned out that it didn’t benefit from the built-in CSRF mitigation available since preview 5 version of the api. The mitigation is quite simple and generates tokens and validates them inside controller actions. As usual, I rather spend my time looking for more complex issues during code audit and I prefer relying on the FxCop automation we have to spot this sort of problem earlier so I implemented a simple rule that will catch where the mitigation should be used. The rule will look for controller actions that are available via POST and look to see if the method declares the ValidateAntiForgeryTokenAttribute. You can read more on how to implement the mitigation in your code by reading Steve Sanderson blog post on the subject.
Installation
-
Copy MVCAntiforgeryTokenChecker.dll in your FxCop rule folder. By default it's under c:\Program Files\Microsoft FxCop 1.36\Rules
-
Launch FxCop and the rule is "AntiforgeryToken used" under "ASP.NET MVC Security" group.
ASP.NET has had a mitigation to prevent against CSRF/One-Click attacks since 1.1 with the use of Page.ViewStateUserKey property. I've implemented a basic FXCop rule to verify if this property is used on each page. The rule is basic so it doesn't look at what is assigned to the property and only looks if something is assigned to it. The ViewStateUserKey property is not full proof. If you are not using viewstate on the page it doesn't help much. You can also review this post regarding limitation of the ViewStateUserKey. I strongly recommend that you include this rule when running fxcop or code analysis in visual studio on web projects.
Installation
- Unzip and select the appropriate rule for the fxcop release you are using
- For Visual Studio Team System 2005 select the fxcop 1.35 version and place it in C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules
- For Visual Studio Team System 2008 select the fxcop 1.36 version and place it in C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules
- The rule can be enabled under the "ASP.NET Security" section and it's called "ViewStateUserKey used"
Update
I've been working with projects using ASP.NET MVC and made some update to the rule to ignore classes inheriting from ViewPage since MVC doesn't use ViewState.
In my previous post, I provided a list of which ASP.NET HTML control property that offers automatic HTML encoding. As a side note, I was made aware that an older version of that file is available from the support files of the Hunting Security Bugs book. I initially received this document from Tom Gallagher team and made some updates regarding BaseValidator and child classes ErrorMessage property so the version I posted is more up to date. I'll remind the book authors to update the file on their side.
The document was targeted to ASP.NET 2.0 developers who were interested to know which control doesn't offer encoding to mitigate against XSS problems. The document is also very useful during code review and I've decided to quickly plug it into FxCop so it can quickly spot areas that should be reviewed.
The rule will load the control encoding information stored in asp_controls.xml and will apply the following logic:
- If properties that don't offer encoding are used, it will be listed in the FxCop result
- If it finds a property that offers encoding but that property is bound to html attribute, it will spot it to make sure that users cannot inject things like javascript: or other handlers
- In the future, it will only show cases where the attribute can be executed. I'm currently looking to potentially integrate the rule with the script mapping project from WASC.
This will give a detailed list of items to review. The aim is not to automatically detect XSS but to identify spots in the code that should be reviewed.
Installation
- Simply unzip the files and put them in the FxCop Rules folder (C:\Program Files\Microsoft FxCop 1.36\Rules)
- Launch FxCop
- The rule can be selected from the Rules tab under the Html Review section
I've had a lot of people ask me which ASP.NET control offers automatic html encoding and the answer I had for a long time was to look at MSDN or even write a quick sample and test the behavior. If you are asking yourself the same question, you can now use the attached document to see if the control if offering the appropriate encoding. The document list all asp.net control and which property offers html, script or url encoding. You can also see which html attribute the property is bound to. This document is quite useful when you are reviewing your code for possible Cross-Site Scripting (XSS) or double encoding problems.
Side note
I was made aware that the initial content was provided as part of the companion content for the excellent book Hunting for Security bugs available at http://www.microsoft.com/mspress/companion/0-7356-2187-X/. The file attached to this is indeed base on the same content since I received it internally by the author's team. I found some slight issues and made some changes. I recommend the file I provide until the book companio content gets updated.
