Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi, Bryan here. Michael wrote last week on static analysis for native C/C++ code, and this week I’ll be following up by covering the tools we use for managed static analysis. The SDL requires teams writing managed code to use two static analysis tools: FxCop and CAT.NET. Both of these tools are freely available to the public, and both tools also integrate very nicely into Visual Studio. If you’re not already using these tools in your development process, I highly recommend downloading and evaluating them, but first let’s take a quick look at each of them.
You may be more familiar with FxCop as the “Code Analysis” feature found in Visual Studio Team Developer (and Team Suite) 2005 and later. If you’re already using Visual Studio, it’s a no-brainer to enable FxCop code analysis: open your solution’s Properties window (or your web site’s Website menu item), navigate to the Code Analysis tab, and check the “Enable Code Analysis on Build” option. If you’re not using VS, you can download the latest version of the standalone FxCop tool (1.36) here.
FxCop comes preinstalled with many useful rules, including rules to help ensure performance (for example, “Do not cast unnecessarily”), globalization (“Do not hardcode locale specific strings”), and maintainability (“Variable names should not match field names”), but the SDL is mainly concerned with the security rules. The SDL requires teams to enable all of the FxCop security rules and fix any violations.
Many of the security rules are focused on detecting misuses of .NET Code Access Security policy. Some examples:
· Do not indirectly expose methods with link demands. LinkDemand checks only the immediate caller’s permissions, it does not perform a complete stack walk like Demand does. Calling a LinkDemand-protected method from an unprotected method essentially allows the caller to bypass the security check completely. In general, Demand is much safer than LinkDemand; any misuse of LinkDemand can create a potential vulnerability to luring attacks.
· Secure serialization constructors. If you place security demands on a type’s regular constructors, you must also place them on its serialization constructors, or else the demands could be bypassed.
· APTCA methods should only call APTCA methods. Assemblies marked with the AllowPartiallyTrustedCallersAttribute (APTCA) that call into other assemblies not marked with APTCA can be used by attackers to perform luring attacks. The attacker (calling from partially-trusted code) could simply call the APTCA method that would then call the protected method on his behalf. (Note that the use of APTCA in itself is banned by the SDL; if it’s absolutely necessary then a manual review of all APTCA methods must be made to ensure no luring attacks are possible.)
While the built-in FxCop security rules are generally focused more on testing whether you’ve used security features in the right way (although it’s easy to write your own FxCop rules to check for almost anything you want, which we’ll talk about later in this post), CAT.NET is focused more on testing whether you’ve written your other features securely. This is a subtle but important distinction and both types of tests are necessary to help ensure secure code. By default, CAT.NET tests for the following vulnerabilities:
· Cross-Site Scripting
· SQL Injection
· File Canonicalization issues
· XPath and LDAP Injection. These attacks work on exactly the same principle as SQL injection (user data is interpreted as code), but for XPath and LDAP queries instead of SQL queries.
· Redirection to User-Controlled Site (aka Open-Redirect Phishing)
· Process Command Injection. This is yet another attack that works on the data-interpreted-as-code principle. In this case, the user supplies improperly validated arguments to a command-line process, which can allow the user to execute arbitrary processes on the server.
CAT.NET also differs from FxCop in the way it performs analysis. Both tools are static IL analysis tools, meaning that they analyze the compiled Common Intermediate Language (CIL) bytecode and not the raw C#/VB.NET/etc source itself. However, FxCop works on an introspection basis, iterating through each assembly type, member, resource, etc, while CAT.NET works by creating a directed call graph and looking for execution paths that represent potential vulnerabilities.
For example, if you wanted a rule to make sure your code doesn’t use MD5 (because it’s been banned by the SDL), FxCop would be a natural choice: you could simply write one method that would iterate through the all of the members in the assembly looking for instantiations of MD5Cng or MD5CryptoServiceProvider classes. On the other hand, if you wanted a rule to make sure incoming querystring data is validated by a regular expression before being adding to session state, CAT.NET would be a better choice. You would create a new rule XML file, adding HttpRequest.QueryString.Item and HttpRequest.Params.Item as “source” elements, HttpContext.Session.Item as a “sink” element, and System.Text.RegularExpression.Regex as a “filter” element. CAT.NET would then analyze the potential execution paths of the application, flagging any data flows that originate with HttpRequest.QueryString or HttpRequest.Params and end at HttpContext.Session without first passing through RegularExpression.Regex.
CAT.NET can run standalone or integrated into Visual Studio, but in either case you’ll need to download it from microsoft.com: you can find the 32-bit version of CAT.NET here and the 64-bit version here. Microsoft online services teams have been using CAT.NET internally for quite a while, and I was extremely pleased when the Microsoft IT Information Security Tools team (formerly the Connected Information Security Group) released it externally.
Finally, as an interesting look at an upcoming technology, check out the DevLabs Code Contracts project. Code Contracts let you annotate your code to express required pre- or post-conditions on methods, just like SAL for native code. For example, you could require incoming method parameter values to conform to a specified regular expression, or require outgoing return values to be non-null. You can use Code Contracts both as a static analysis tool, to test for possible contract violations, and as runtime checks to actually enforce the conditions set. Like both FxCop and CAT.NET, Code Contracts can be installed either standalone or integrated with Visual Studio.
If you’re following the SDL Optimization model, use of static analysis tools is deemed a requirement for the ‘Advanced’ maturity level.
Question about your static analysis usage. Is the usage policed in any way or is it mostly a useful tool for developers who choose to take advantage of it? What are the quantitative or qualitative benefits your team receives from using static analysis? Thanks!
Hi Andy, great question. Yes, use of these tools is enforced as part of the SDL. We have an internal SDL requirement tracking tool that teams must register with and upload their static analysis results to. (On a separate note, we also just publicly released the SDL Process Template for VSTS, which is similar to our internal tracking tool; check it out at http://msdn.microsoft.com/en-us/security/dd670265.aspx.)
I don't have quantitative metrics as to how many SQL injection, XSS, etc vulns that static analysis has prevented in our products and services. But we do believe there is significant ROI for these tools given the severity of the issues they detect (like SQL injection) and given their relatively low cost of use (once they're integrated with the build system, there's not much more effort required).