Published: 30 Apr 2010
The Open Web Application Security Project (OWASP) is hoping an overhaul of its top 10 vulnerabilities list will...
help enterprises more easily apply the list to their software development lifecycle. The organization changed the methodology it uses to categorize coding errors in the latest version of the Top 10 List issued in April, adding risk to the equation.
"Wherever we rate a risk, we have a big question mark so that you can fill in your threat agent and your business impact," says Jeff Williams, volunteer chair of OWASP and a co-author of the OWASP Top 10. "You can rate these risks for yourself, for your application and for your organization."
It's the first time in three years since the last major revision to the OWASP list. Ultimately, the change in methodology has resulted in ranking the 10 most critical Web application coding errors by risk rather than vulnerability frequency. Factoring in risk has bumped injection errors ahead of cross-site scripting (XSS) flaws. It also stirred some debate in the organization, according to Williams, because two common coding errors that had long been on the list -- malicious file execution and information leakage -- have been dropped from the top 10. In their place are two new risk categories: unvalidated redirects and forwards and security misconfiguration errors.
The OWASP coding errors list was first released in 2004 and was modeled after the SANS Top 20 vulnerabilities list, which at the time focused on network security vulnerabilities, says Williams, who also heads Columbia, Md.-based application security services firm Aspect Security. While OWASP always tried to focus on risks, it used the term "vulnerabilities," creating some confusion, he says.
"People would look at the list and say that that's not really a vulnerability, that's more like an attack or that's more like an impact," says Williams.
For example, SQL injection is an attack, but people also use the term to describe an outcome when a SQL database gets compromised. People also use it to describe a vulnerability if a developer didn't do proper quoting or escaping of data that's gone to the database or failed to use a prepared statement that prevents injection.
"We're trying to mature people's understanding of application security a little bit," says Williams. "They shouldn't just be focused on vulnerabilities. They should really think about how vulnerabilities can be exploited in their environment and the impact a successful attack could have."
The purpose of the OWASP Top 10 is to raise awareness, but the changes to the list make it even more useful, says Ryan Barnett, an OWASP volunteer, and director of application security training at Breach Security..
"You want something that's a bit more consumable for end users," he says. "If you start talking to C-level executives about vulnerabilities their eyes glaze over. You have to start talking about risk and how it impacts the business."
While vulnerability lists can get people thinking more about software security, they could be misleading, says application security expert, Gary McGraw, chief technology officer of Cigital, a provider of software security services.. McGraw has long been an outspoken opponent to the usefulness of public vulnerability lists.
McGraw studied 30 enterprises last year and developed what he calls a Building Security in Maturity Model (BSIMM), which includes a framework designed to help other firms put software security best practices in place. He says none of the firms he studied use publicly available vulnerability lists. The lists often can't be applied to an organization's specific use case, ending up helping auditors more than developers. McGraw advocates the use of code analysis tools to find bugs and a greater reliance on security requirements to conduct software testing.
"It's time to start doing science and talk about what's actually happening and the impact of what we're doing and no longer time to be theorizing from our arm chair," McGraw says.
OWASP's Williams says the list is no longer a simple catalog of bugs, but a starting point where companies can apply their specific risk profile to determine the areas that deserve the most attention.
"In our work we look at millions of lines of code every month and test lots of apps and there is a lot of commonality among Web applications," Williams says. "It's not a simple checklist. A lot of organizations are using it to improve their processes."
Robert Westervelt is the news editor of SearchSecurity.com. Send comments on this article to email@example.com