A set of code inspection rules using FxCop, mostly dealing with detecting vulnerabilities to various attacks and managing an application's attack surface.
C#
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
CustomRules
FxCopUpdater
Empty.FxCop
FxCop.pdf
FxCop.pptx
LICENSE
README.md

README.md

FxCop

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

Projects

  • 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

List of 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...