The rise of open-source, component-based development hasn’t come without risks, according to the Open Web Application Security Project’s (OWASP) 2013 Top 10 list.
The OWASP Foundation is a not-for-profit organization focused on improving software security. Now in its 10th year, the OWASP Top 10 list names the most critical Web application security risks, according to the foundation. “These are the mistakes that developers make most often that lead to significant exposures,” said Jeff Williams, founding member of OWASP and the Top 10 list’s creator and coauthor. “SQL injection tops the list because that’s the mistake developers make the most often.”
The first new risk to be added to the OWASP Top 10 list in three years, “Using Components with Known Vulnerabilities” highlights the importance of developers using secure components in applications to avoid exploitation by hackers. As stated in the 2013 OWASP Top 10, “Vulnerable components, such as libraries, frameworks and other software modules, almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts.”
According to OWASP, two of the most common vulnerable components are Apache CXF’s authentication bypass and Spring’s remote code execution, which were downloaded 22 million times by developers in 2011. And, according to application security consulting firm Aspect Security (in “The Unfortunate Reality of Insecure Libraries”), developers downloaded at least 17 additional vulnerable libraries in 2011. Four of the most-downloaded, vulnerable libraries in 2011, according to Aspect Security, were the Google Web Toolkit, Apache Xerces, Spring MVC and Struts 1.x. Aspect Security published the paper based on 2011 research done in conjunction with component life-cycle management solution provider Sonatype.
To avoid using vulnerable components, developers should always keep their open-source components up-to-date, said Williams. According to OWASP, many open-source projects do not create security patches for older versions of components; instead, most simply fix the problem in the next version. This can present a problem for developers who might not understand the risks they are taking by using out-of-date libraries. “We think it’s important enough that every software project ought to think about whether the libraries they’re using are secure enough for what they’re using them,” said Williams. “It’s critical for developers to make sure they’re not using out-of-date libraries.
“And that’s why [the vulnerable components issue] has been added to the OWASP Top 10. Because the stuff on there is really unacceptable; if you’ve got any of those things listed, then you’re really negligent.”
To learn more about components with known vulnerabilities, Williams said developers can search an online database maintained by the MITRE Corporation, a not-for-profit organization. It has its own independent research program, and it maintains the MITRE Common Vulnerabilities and Exposures (CVE) list, a free, searchable database of publicly known security vulnerabilities, including component-related ones.
Developers can also use tools such as Sonatype’s CLM or Aspect Security’s Contrast to find out which of their components are at risk. Williams said that there are also free open-source tools that will simply tell developers whether or not the library they are using is the latest one available.
As crucial as it is for developers to make sure they’re not using components with known vulnerabilities, Williams emphasized that developers should also remember the rest of the security risks that are listed in the OWASP Top 10. “I just don’t want to lead people to the false impression that if you lock down your libraries, then you’re done and your apps will eventually be secure,” he said. “Because it’s not even close to true. Only a tiny fraction of the vulnerabilities that we discover are related to libraries.
“[Vulnerable components] is a nice one to tackle because it’s relatively easy; you don’t have to change any code. Generally, you just go update your libraries and you’re done. But just focusing on [vulnerable components] is dangerous because it will give companies a false sense of security. They need to focus on the other nine of the Top 10 as well.”