Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Apply Visual Studio Code Analysis to Beef Up Security : Page 2

Visual Studio's code analysis feature offers hidden extensibility opportunities for writing custom security code review rules.


advertisement
Writing Custom Code Analysis Rules
In this demonstration, you'll see how to build a custom code analysis rule in VSTS—a simple security rule that looks for potential password disclosure by identifying any fields in the application that appear to be password values. The rule shows the process by which you can extend the base rules to implement whatever logic you desire.

Your best friend in understanding VSTS code analysis rules is Lutz Roeder's Reflector for .NET. Because the code analysis rules and their extensibility are not documented, your best examples are the rules that ship with VSTS. After you've reviewed the basics here, you'll be able to use Reflector to review the source for bundled rules, and that will help you to understand more complex rules. The bundled rules are located at C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules. For example, to review the security rules in Reflector, open the SecurityRules.dll file, and examine the source code and resources bundled in the assembly.

The first step in creating a custom rule is to inherit the BaseIntrospectionRule class so you can access the interfaces to the code analysis introspection engine. Instead of inheriting directly from the base class for every rule you write, I recommend you create a base class that inherits from the BaseIntrospectionRule class and then inherit your subclasses from that. You must provide three arguments to the base class constructor: the name of the custom rule, the name of the XML file containing rule data, and a reference to the rule assembly type. By using a common base class that "knows" the last two parameters, you need to supply only the rule name with each new custom rule. The file BaseRule.cs contains such a base class:

using System; using Microsoft.Cci; using Microsoft.FxCop.Sdk; using Microsoft.FxCop.Sdk.Introspection; namespace CustomSecurityRule { public abstract class BaseRule : BaseIntrospectionRule { protected BaseRule(string name) : base(name, "CustomSecurityRule.Rules", typeof(BaseRule).Assembly) {} } }

Note the references to two key Microsoft libraries in the base class: Microsoft.Cci and Microsoft.FxCop.Sdk. The Microsoft.Cci assembly, known as Common Compiler Infrastructure, includes compiler-level classes for examining low-level programming constructs in the target code, such as methods, fields and classes. The Microsoft.FxCop.Sdk assembly contains the mechanism for running code analysis rules and displaying results natively in VSTS.

To create the sample rule called "Possible Password Disclosure," create a class named PossiblePasswordDisclosure that extends the base rule. In the rule constructor, provide the name of the rule as the only argument. You'll find the class in the downloadable source in the CustomSecurityRule.cs file, but here's the code:

public class PossiblePasswordDisclosure : BaseRule { public PossiblePasswordDisclosure() : base("PossiblePasswordDisclosure") { } public override ProblemCollection Check(Member m) { Field field = m as Field; if (field != null) { string name = field.Name.Name; string uppername = name.ToUpper(); if (uppername.IndexOf("PASS") != -1 ) { Problems.Add(new Problem(GetResolution(name))); return Problems; } else { return null; } } return null; } }

The overridden Check method in the rule class does all the work. The method overloads the Check method in the BaseIntrospectionRule interface, and it's intended to be called repeatedly while iterating over each member of the classes on which you're performing code analysis. This example searches every member in the class for fields that contain "pass" in the name, and flags these as potentially disclosing password values. The code first tries to convert the member to a field; if that does not succeed, then the member is not a field, so the method skips it. If it is a field, then you examine name. If the field name might be a password field, then you create a new Problem instance and add it to the Problems collection provided by the BaseIntrospectionClass. The GetResolution method lets you look up rule-resolution messages from the XML rules data file so you can display them to the developer in VSTS.

The XML file containing rules data is the final piece in the puzzle for putting together a custom rule. The example below, contained in a Rules.xml file, provides the friendly name, the rule description shown in VSTS, and the rule-resolution information that users see after a rule has flagged a problem.



<?xml version="1.0" encoding="utf-8" ?> <Rules FriendlyName="Custom Security Rule"> <Rule TypeName="PossiblePasswordDisclosure" Category="Custom" CheckId="JS0001"> <Name>Possible Password Disclosure</Name> <Description>The field '{0}' in your application may be a password field and could be vulnerable to password disclosure if the value is visible and unencrypted.</Description> <Url></Url> <Resolution Name="Prefix">If the field "'{0}'" is a password field, it should be protected through encryption and obfuscation.</Resolution> <MessageLevel Certainty="95">Error</MessageLevel> <FixCategories>NonBreaking</FixCategories> <Email></Email> <Owner></Owner> </Rule> </Rules>

You include the rules file in your class library project. Mark it as an embedded resource so that it gets embedded in the assembly during compilation.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap