A set of code inspection rules using FxCop, mostly dealing with detecting vulnerabilities to various attacks and managing an application's attack surface.

• FxCopUpdater: A simple utility to add/remove DLLs in a given directory to an FxCop project, keeping it up-to-date
• CustomRules: the custom FxCop rules

There's also some information on these in the CustomRules.xml file and the PowerPoint deck.

Potentially Useful As-Is:

• SuspiciousGetRequestsRule: This flags any methods that allow HttpGet (as opposed to HttpPost) and have keywords that indicate that they may alter data on behalf of a user. This is useful in conjunction with a site-wide anti-CSRF solution to ensure that sloppy coding doesn't open up a breach.

• MissingHttpMethodRule: Falls under the category of "managing your attack surface". Any new Action without an HttpGet or HttpPost specified is flagged to be code reviewed. Used in conjunction with SuspiciousGetRequestsRule.

• JSONAllowGetRule: Protects against JSON Hijacking by flagging any action that returns JSON and overrides the default MVC behavior (DenyGet).

• XSSRule: Falls under the category of "managing your attack surface". Flags any user function that returns an IHtmlString as needing code review for possible XSS vulnerabilities.

• StaticDisposableRule: Not a security-related rule; any static variable of a type that is IDipoosable is probably bad mojo.

Useful With Minor Modifications: (see the "MOD:" comments in the source code)

• MissingRoleCheckRule: Actions or Controllers that don't have attributes for Role checking (missing authorization control)

• ContextInDataDLLRule: Not a security-related rule; flags any use of .Context properties on the data layer of your application, as they may not be instantiated or may break caching of their results.

Specific to Our Organization/Application: (but maybe you can get some ideas based on them)

• SkipAuthorizeAttribute: We've got a default platform-wide behavior to ensure that any request is authorized (user is logged-in) ... unless you add this attribute. This flags uses of this attribute for a code review.

• UnloggedEmailRule: We want to make sure people send email through our company's email library, not by hitting system functions directly.

• UnloggedThreadingRule: We want to make sure people spawn threads through our company's threading library, not by hitting system functions directly.

Totally Experimental: (maybe you can complete what we've started)

• SafeSqlBuilderRule + SQLInjectionRule: These, in conjunction, look for potential SQL injection by ensuring that potentially "dirty" (affected by user input or unknown input) strings aren't passed as SQL to the database. It's nowhere near production/release ready, but it has caught legit issues in our code base along with the false alarms...