Essentials of static source code analysis for Web applications

Using static source code analysis as a security tool and an information risk management tactic is nothing new. The tools are mature and the benefits of integrating source code analysis into the SDLC have been pushed on us for years. Even with all this knowledge it occurs to me that many people – developers, QA testers, network managers, and security executives alike – still don't quite understand what's involved with source code analysis. When talking with existing and prospective clients, many people don't initially see the value in source code analysis and are, therefore, reluctant to invest any money in it. It's as if they have certain pre-conceived notions that were perhaps brought on by the security marketing beast. Usually once they get past the vendor fluff and hear the good, bad, and ugly about source code analysis, they're able to make informed decision as to whether or not it's a good fit for their business. Here's my take on it.

It's the process of running a scanning tool against your source code (C#, Java, VB.NET, etc.) to uncover security and other quality issues. The word "static" is used because the process looks at the source code from a static perspective. Certain source code analysis tools can also perform dynamic analysis (sometimes dubbed hybrid analysis) that looks at generated code and other behaviors during application run time.

First, off it's very easy to do. It also automates the manual analysis process – something that's often an exercise in futility especially with today's complex applications. It can find defects that the human eye, and oftentimes penetration testing tools, would never find. Obviously there's a compliance payoff – the thing that management typically understands and likes to see in this context. More secure applications equals less worry over security breaches and compliance violations and audit failures. Finally, it's not just for Web applications. You can test any source code regardless of how it's used: client/server, browser helper objects, standalone applications, you name it – there's a tool out there for you.

Options include commercial products like Checkmarx and Klocwork Solo as well as freeware/open source tools such as Microsoft's FxCop and FindBugs. Some static analysis tools plug into your IDE while others are standalone products. Being a security consultant I prefer the latter so I don't have to worry about keeping a copy of Visual Studio or other IDE on my test system. However, developers and testers may prefer it that way. Do yourself a favor and get a trial version of any products you're considering before making the leap.

Some static analysis scans I've done have taken only a few minutes, others have taken upwards of an hour, while others didn't finish at all due to incompatibilities between the source code and the tool I was using. So, it depends. Determining factors include the amount of code you're testing, the processing power of your test system, and the tool you're using. By large it's a simple and quick process.

Depending on the type of code you're testing and the tool you use, you may find issues similar to what you uncover during penetration testing such as cross-site scripting and SQL injection. Hopefully you'll find others that are not so obvious. Vulnerabilities I've come across that were unique to static analysis include improper resource shutdown situations in C# that could lead to denial of service conditions, unused methods in Java that can create backdoor access, weak implementations of encryption and data storage, general error handling and recovery, and, of course, buffer overflows. The possibilities are endless. All in all many of these issues could take an eternity to uncover doing a manual code reviews but are still exploitable application vulnerabilities nonetheless. This is why you need to consider static source code analysis in addition to penetration testing. It's the only way to find everything that counts.

Source code analysis is in no way a replacement for blackbox security assessments/penetration tests that involve automated scans and manual analysis from a hacker's eye view. I can say that in the security assessments where I've done both penetration testing and source code analysis, the penetration testing by far revealed the majority of the application weaknesses. But it was the handful of nuggets that the source code analysis revealed that helped make a big difference. Furthermore, if you're looking for an independent view of your source code rather than performing this exercise in house, the expertise is kind of sparse. There's also the issue of price with the commercial static analysis tools. If you've looked into this much I'm sure you've noticed that some vendors are very proud of their products and want to charge you accordingly while others are priced very reasonably considering the return you're going to get. Capitalism and competition at their finest! It's your choice – just do your homework first and make sure you find the best fit.

With the presence of Web applications across virtually every facet of the business, it's important that you do what you can to minimize your security risks. This is where testing your actual source code comes into play. While static source code analysis is not everything it'll certainly help you assess your entire attack surface and it's a worthy component of an overall information security strategy you, and especially the powers that be, need to be thinking about.