Microsoft recently released a new build of CAT.NET, the Code Analysis Tool from the Microsoft IT Information Security Tools Team (formerly known as the Connected Information Security Group). This is the same group that works on the AntiXSS Library that I wrote about in "Fighting Cross-Site Scripting with Anti-Cross Site Scripting Library 3.0." The tool is a static analysis tool that performs security reviews on the intermediate language (IL) contained in .NET project binaries. CAT.NET uses tainted data flow analysis, sometimes called tainted-variable analysis. This type of analysis attempts to identify what sources of untrusted inputs could affect trusted parts of an application.
CAT.NET couldn't be easier to use. It is implemented as a Visual Studio add-in that installs a CAT.NET Code Analysis item to the Tools menu. Select that item to open the CAT.NET window, and click the green arrow to start analysis. After several moments (depending, of course, on how large the project is), you get the results. The following image shows the results of running the tool on a single-page website that has some fairly extensive code behind it.
CAT.NET identified only two potential problems—a redirection vulnerability and a single cross-site scripting possibility. But because the input value from a query string is used extensively in the code, CAT.NET found 36 locations where it could cause a problem.
In a fresh installation of CAT.NET, you get eight rules that define problems that the tool looks for. The rule definitions are transparent, consisting of easily viewed XML files in a set of folders that categorize the tools. The XML defines sources, sinks, and filters. The tool finds security vulnerabilities by tracing a data-flow path from various sources, such as user input and exceptions, to a destination in the list of sinks. It can filter the data flow, in which case the vulnerability is ignored. Each rule lists the sources, sinks, and filters defined in XML files in the \Rules directory where CAT.NET is installed. You can easily add your own rules if you take the time to figure out the proper XML structure.
In my tests, the tool didn't always identify real risks, usually because it wasn't able to get enough code context information to see any mitigations in the code. For example, it flagged my use of a query string variable under the Cross-Site Scripting rule to read data from the database, even though I explicitly and immediately converted the value to an integer before using it. Further, the user is welcome to view any and every record associated with valid integer values. This "problem" repeated throughout the code on one of my pages. Nevertheless, it was good to have that flagged, letting me take a fresh look at the code to reassure myself that it was not a real vulnerability.
CAT.NET doesn't have the prettiest interface, nor is it a particularly fast tool. It is implemented as a dockable window in Visual Studio, but it's a wide, three-paned window that doesn't really work well as anything but a floating window. And text wrapping is ugly. Performance isn't a big issue because you're not likely to use the tool on every build, just at benchmarks during development. But these are minor quibbles; not everything in life needs to be pretty or fast!
It's definitely worthwhile to check out CAT.NET and see what it finds in your code. The results won't be pretty, but if it helps you find just one vulnerability in your code, it's time well spent.
Resources:
You can download the new build of CAT.NET at these URLs:
32-bit version of CAT.NET
64-bit version of CAT.NET
The best place for information about CAT.NET is at Microsoft's Connected Information Security Group's blog. They recently changed URLs, but most of the interesting CAT.NET background posts are at the old address, so check out both:
Reference
Don Kiely