The Open Web Application Security Project (OWASP) recently released its "Top 10" Web application vulnerabilities...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
for 2007. Topping the list is cross-site scripting (XSS), which OWASP chair Jeff Williams likens to an infestation of termites silently eating away at your house -- and just as hard to get rid of.
Also at the top are two types of vulnerabilities that have stayed below the radar to date -– cross-site request forgery (CSRF) and insecure storage and communications. They're in the top 10 because the consequences are that serious, according to Williams.
The methodology OWASP used for the 2007 list was based on the Common Vulnerabilities and Exposures (CVE) list, which is operated by the Mitre Corp. and sponsored the by the Department of Homeland Security. The list provides an index of standardized names for security vulnerabilities.
"In 2002, our first Top 10, there was no data available, so we guessed based on our experience and what we had seen in the market. And we got pretty close to the mark if you look what the data shows today," Williams said. "But today we've got really good data coming out of Mitre in the CVE project."
Williams said OWASP took the CVE data related to Web application security and built the Top 10 categories based on what Web application developers should focus on. The Top 10 for 2007 are as follows:
- Cross-site scripting (XSS)
- Injection flaws
- Malicious file execution
- Insecure direct object reference
- Cross-site request forgery (CSRF)
- Information leakage and improper error handling
- Broken authentication and session management
- Insecure cryptographic storage
- Insecure communications
- Failure to restrict URL access
Williams said that what the industry is seeing in terms of XSS problems is the tip of the iceberg, and he expects it to become a "deluge" because it's such an easy mistake to make.
"Any time you take input from the user and put it in a Web page, the potential is it could contain script," Williams said. "Web apps take input from so many places, and they reformat it and spit it out in so many different places. HTML is the worst mashup of code and data ever because it leads to security problems."
Although any instance of XSS is trivial to fix in development, he said, the sheer volume developers face with thousands of form fields and URL parameters makes it difficult.
"Companies should be building frameworks and patterns that protect against cross-site scripting into their platforms. You really need a common approach for dealing with this problem everywhere. Then you can write rules for static analysis tools to detect [XSS vulnerabilities]; otherwise developers are on their own. It's more like termites than a big caved-in wall in your house. It's hard to get them all out."
In contrast, Williams said organizations seem to be getting a handle on SQL injection, even though it remains on the Top 10. "Companies that decided it's a problem have started using parameterized queries everywhere. If they have a security team, we're seeing progress," he said.
New to the list, and where OWASP decided to veer from its methodology, is the area of CSRF. "The data didn't put it in the Top 10, but it's so important and so widely ignored that as a community we made the decision it has to be in Top 10. Virtually every Web app out there has this problem, and the consequences are serious," Williams said.
With CSRF, an attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable Web application, forcing the victim's browser to perform a hostile action.
"It can be used by attackers to do anything you can do," Williams said. "It's been known about since 2000/2001. What's hot in the application security market is not always necessarily what represents the biggest risk; what gets reported is not necessarily the riskiest thing. Vendors are pushing products that solve certain problems. If the tools don't solve [a problem], they won't talk about it. That leaves it up to organizations like OWASP to tell the truth, to say what the real problems out there are."
He added, "We believe cryptography is under reported as well. In our list it's the 8 and 9 slots, but it was not represented in [CVE] data." Williams said OWASP put this in the Top 10 because the vulnerabilities are found so frequently in Web applications, and it represents a high risk.
Dropped from the list
The 2007 list also dropped some previous Top 10 vulnerabilities, including input validation and buffer overflow. "Unvalidated input is still critically important, but we dropped it because it's at a higher level of abstraction than the other items in the list; many items in the list would be part of a broader issue of unvalidated input," Williams said.
Williams added that the data strongly supported dropping buffer overflow, though he stressed that it was because in developing Web applications people have moved away from languages such as C and C++ that are susceptible to buffer overflows.
"It's not like we as a community got smart and learned how not to make buffer overflow mistakes," Williams said. "I think that's astounding and sad that we can't solve a relatively well-understood problem, and it doesn't bode well for cross-site scripting, which we've known about for a decade."
What OWASP hopes to accomplish with the Top 10 is that organizations will use it as a basis to establish processes and tools for addressing these vulnerabilities. "This stuff isn't easy, but once you get processes in place and teach developers about these issues you really can make progress and build Web applications that are more resistant to attack," he said.
Reaching out to developers is also part of the mission, Williams said. "The number of developers trained in application security is trivially small. Until we get the message to all developers, we will still make these mistakes; that's OWASP's challenge. We've done a pretty good job evangelizing to the security community, but it's time for us to take our message to developers so they really change their behavior," he said.
Dig Deeper on Building security into the SDLC (Software development life cycle)