Application security is getting a new push as rules governing the payment-card industry mandate many businesses undergo a software code review or make use of a Web application firewall starting later this summer.
“Application security is high on everybody’s radar,” says Brad Friedman, CIO at Burlington Coat Factory, which like other businesses that handle customer payment cards is obligated to comply with Payment Card Industry (PCI) security guidelines. For Friedman, who says his company has already locked down PCs and point-of-sale devices in its 400 stores, the concern remains for companies how to avoid the kind of credit-card data-breach fiasco that TJX had last year.
But the question is: Which of these soon-to-be PCI-required approaches to take? And even if you’re not required to go with one of these approaches, does either of them really do the trick?
There’s a wide range of tools and services that help automate code analysis for purposes of finding security flaws in applications, including those from Fortify Software, Klocwork, Ounce Labs and Veracode. And there are application-penetration testing tools such as the Core Security Technologies' software Core Impact, which uses an agent-based approach.
However, many security experts point out that automated code analysis has its limits, especially when it concerns finding flaws in the underlying business logic of an application.
“Source-code analysis won’t find all security vulnerabilities,” acknowledges Brian Chess, chief scientist at Fortify, which makes tools for static-code analysis and real-time analysis of applications. “It will find a lot of vulnerabilities that can be exploited through buffer overflows, cross-site scripting and SQL injection. But source-code analysis can’t tell you about business logic flaws. It can’t find design flaws.”
Others agree.
“Closed source or open source, it comes down to the programmer and their psychology,” says Joe Stewart, senior security researcher at Atlanta-based SecureWorks. “Code inspection will find common mistakes, such as buffer overflows. But finding errors in logic is much harder.”
Business logic flaws often are made in the design of an application’s authentication process, Stewart notes. “Suppose it checks one letter at a time — it gives attackers a clue. Or a logic bug may involve giving people access to something they shouldn’t have. Programmers may skip over the critical checks so they can do it faster.”
Stewart added that another common error in writing code for the Web is putting the public backup of a file in a public directory that can be read on the Web, allowing a clever attacker to download PHP code to read the mistakes in the code.
Web application firewalls (also called application-layer firewalls) are generally regarded as an appliance, server plug-in or filter that can apply a set of security rules to the back and forth of HTTP traffic to identify and block certain types of attacks. (Compare Secure Web Gateway products.)
Reading, Pa.-based Sovereign Bank, with 800 retail locations plus Internet banking, uses the WebDefend Web application firewall from Breach Security. Web Security Manager Aaron Weaver says the product is useful for learning about the defects in an application while it’s running, such as spotting where a SQL injection or cross-site scripting attack might occur due to a programming error.
“Web application firewalls will block the malicious traffic, and it gives you time to correct the code,” Weaver says.
Sovereign Bank also uses its Web application firewall to watch outbound traffic to detect suspicious activity involving outbound customer-account numbers. In addition, the bank deploys periodic scanning — in this case, from SPI Dynamics — to look for vulnerabilities. But Weaver says his impression is it only catches a small portion of the application problems because these techniques don’t find the mistakes in business logic.
“For instance, it might be where two systems are handing off data to each other, and the way the authentication flows from one to another fails in the application,” Weaver says. These sorts of business-logic mistakes are dug out through a lot of manual testing and code review, he adds.
"Web application firewalls are good for finding technical vulnerabilities," says Danny Allen, director of security research at IBM Rational, which makes the Rational AppScan tool for analyzing software holes. "But the other kind of problem is in the business layer in the logic. This needs to be addressed in collaboration between the security team and the development team. It's about education in building applications," he says.
Ed Adams, CEO at Security Innovations, a consultancy specializing in application security risk assessment, also sees poor coding practices as the central problem.
“The bigger problem is the insecure way that applications are coded today,” he says. “Web application firewalls catch a lot of the low-hanging fruit, like a SQL-injection attack. But they don’t catch business-logic attacks.”
Some of the most egregious business-logic errors that Adams has recently observed have been associated with software cookies, the small data parcels sent from a server to a Web browser for purposes of authentication, tracking or maintaining specific information about the user.
“At one e-commerce site, we found we could just open it, see the session ID and change the price,” says Adams. “This is ‘cookie poisoning,’ and it’s very common. The problem is once the cookie was issued by the server, they weren’t re-validating it. The shipping was calculated the same way.”
But nobody thinks Web application firewalls are a waste of time and money.
Paul Asadoorian, senior network security engineer at Oshean, a consortium providing network and security services for several Rhode Island universities, healthcare organizations and the state government, points out that ModSecurity, the open-source Web application firewall plug-in for the Apache Web server, is very popular at universities to prevent cross-site scripting and other attacks.
Rss FeedRss Feed
The Leader in Network Knowledge
Comment