Software code reviews involve static and dynamic testing tools to check for coding errors, but pesky application logic flaws -- errors in the steps an application takes to perform properly -- will always need to be reviewed by a human, according to a software security expert. But getting an organization to dedicate the time and patience necessary to discover the issues can be difficult, said Rafal Los, a noted software security expert...
and evangelist at Hewlett Packard who detailed the challenges of detecting them last week at the 2012 InfoSec World Conference and Expo.
Unfortunately, tools are essential to being able to scale and do more, but the analysis is never going to replace that human aspect of software security.
Rafal Los, evangelist, Hewlett Packard Co.
“If you’re looking at an application that is corporate-critical, you are going to need to throw people at it and technology at it and give it more than a passing glance,” Los said. “Unfortunately, tools are essential to being able to scale and do more, but the analysis is never going to replace that human aspect of software security.”
Application logic flaws could be used by an attacker to perform a variety of costly tricks without the need for malicious code, and they rarely signal alarm bells until long after the mischievous activity is completed. The costly software errors typically cause an application to perform incorrectly, allowing savvy users the ability to give themselves steep discounts on products, an inordinate amount of rewards points and other costly benefits.
Scanning tools are not going to find the errors, according to Los; an architectural analysis is essential in catching them before they cause trouble. Software developers sometimes make logic errors by streamlining steps within an application in an effort to make it perform more efficiently. Missing steps could be as simple as failing to validate a payment has been completed before rewarding loyalty credits or assigning too much trust between a webpage that has SSL and one that doesn’t. “The data interchange between those pieces of the application is important,” Los said. “We need to know how information migrates and how it gets filtered back and forth between them.”
Attackers can hijack the process execution, making the application do something slightly different. A person can game parallel processes, logging into an application twice from two different time zones or perform fraudulent or phantom transactions. Los said he’s seen people create phantom inventory, buying negative 500 units of a product. “All of a sudden the company has 500 units of something that doesn’t exist,” he said.
A more sophisticated attacker can exploit race conditions, when multiple systems write to the database server at the same time. If the database is not properly set up to respect timestamps and transaction processing, it can overwrite itself and create major problems for database administrators, Los said.
More organizations are choosing to conduct an architectural analysis to uncover logic flaws, said software security expert Gary McGraw, CTO of Cigital Inc. McGraw, who oversees the Building Security in Maturity Model (BSIMM), said approximately half of bugs can be found with a code review and the other half with an analysis, “so it’s essential that security analysis includes both.”
“We believe architectural risk analysis (ARA), sometimes called threat modeling, is just as important as code review and even more important than penetration testing,” McGraw said.
Los said a member of the QA team should manually execute application processes through third-party proxy and look for the application logic flaws. Walking through the application, pathways must be documented and traced to examine the way the application behaves during each step of the process.
“You are relying upon your ability to find and make connections that otherwise go unnoticed,” Los said. “You’re looking for decision points; points in the app where decisions are being made; the proverbial fork the road, when a decision takes you down one way or the other.”
Careful mapping and note taking can identify the way application parameters behave and document behavior that could be logically exploited.
“This kind of review requires your brain – it requires you to look at the application steps and do some manual analysis,” Los said.