Software flaws have been the route that hackers have followed in many expensive online thefts, including the SQL injection attacks that led to the highly publicized credit card breaches at Heartland Payment Systems Inc. and Hannaford Brothers Co.
Static and dynamic software scan tools offer one way to eliminate many software security vulnerabilities, and they are critical at each step in the software development process. The subtle errors that hackers utilize to attack online applications, however, require additional measures. VARs and resellers currently offering scan products can further assist their clients by providing source code review services. In this tip, we'll review how a security-focused source code review can reduce or eliminate these errors.
Internal staff reviews are not sufficient
Peer code reviews have been used for many years, but they are often ineffective. Reviews may break down due to disagreements on coding style or simply due to personality clashes among project members. Injecting an experienced lead reviewer from outside the team can maintain focus on the important task: identifying and eliminating ways that a hacker can gain access.
The skill set required to design and implement a software application is not the same as the skill set required to find flaws. Software engineers focus on creating an application to meet a business need. The normal user, someone who wants use an application to make a purchase or check his bank balance, for example, is foremost in the engineer's mind.
A security reviewer -- someone who is trained to find flaws -- focuses on a different type of user: the individual who is intent on gaining access to credit card numbers or customer passwords.
Security-focused source code reviews
It's important for reviewers to keep up with the latest hacker techniques, yet experiences over the past few years have shown that most well-publicized attackers used well-known methods. For example, SQL injection has been understood for years but was responsible for both the Heartland and Hannaford credit card breaches. Software engineers may intend to place defenses against SQL injection in their code, but an experienced reviewer can spot the way an attacker slips an improper input string past the defenses.
A security-focused code review zeros in on the types of errors developers have made in the past. The following are a few of the areas that experienced security code reviewers examine:
- Developers understand that any user-supplied data must be checked, but often assume that data generated within the application doesn't exceed the proper length. Confirm that each place in the code where data is copied into a buffer has a check on the amount of data. A bug in an internal routine may cause too much data to be passed, resulting in a buffer overflow elsewhere in the application.
- Examine each case where a cookie is read and an action is taken based on the contents of the cookie. Developers assume that since their code generated the cookie, there is no need to verify its contents. Users, however, can edit cookies to exploit an application flaw. Each program has a set of possible data that will be placed in a cookie. If you spot data that the program wouldn't write, it means someone has modified it.
- To avoid SQL injection, which allows attackers to input corrupted SQL queries that lead to malicious code execution, examine carefully any location where SQL queries are generated based on user input. Attackers have used clever encoding techniques to hide SQL commands within input strings. For example, attackers have camouflaged control characters by inserting the decimal or hexadecimal string that defines the character.
In addition to looking at specific types of software security vulnerabilities, the reviewers can instruct developers on a range of helpful tools. Each development environment such as Java, Visual Basic or .NET offer a set of routines that developers can use to automate tasks such as verifying input strings and SQL commands. Channel partners must stay up to date on these tools and instruct developers about how to use them.
Design in security and review before final release
The initial engagement with the reviewer should take place during initial design. It is much less expensive to build in security at design time than after errors have been implemented and testing is underway.
Reviewers should point out errors such as the selection of a weak encryption technique. They can review class structure in object-oriented code to ensure that access to critical data is encapsulated at the lowest possible level. Lack of care in parameter passing can also create vulnerabilities. Unlike languages such as C, object-oriented languages like C++ and Java do not perform strict type checking, a function that catches any attempts to pass a parameter that isn't of the correct data type.
After coding and testing is complete, a final detailed code review should be held before the application goes online. There is often pressure to release an application without taking the time for final review. In some cases, the staff understands that further effort is required to ensure application security but faces a push to release immediately. An external reviewer can resolve the issue.
About the author:
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.