Micro Focus is now part of OpenText. Learn more >

You are here

Home/Security/Application Security

You are here

Home/Security/Application Security
Countdown to controversy

OWASP Top Ten update: What your app sec team needs to know

public://pictures/John-Mello-Journalist.png
John P. Mello Jr. Freelance writer
Old door and lock
 

A controversial change in a list of the top-10 critical application security risks appears to have derailed the schedule for the list's release. The Open Web Application Security Project (OWASP)'s list was expected to be finalized this summer, but it now looks as if that won't happen until later this year.

Since its first release in 2003, the OWASP Top Ten Project, which is revised every three years or so, has become an important reference point for developers and the security community. It's cited by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, the FTC, and others.

There can be hundreds of potential vulnerabilities in an application. "The Top Ten was a massive innovation in 2003 because it was 10 things that made that inscrutable list of potential vulnerabilities tractable for a small business or large enterprise," explained John Steven, a senior director at Synopsys, an electronic design automation, semiconductor IP, software quality, and security solutions provider.

In the proposed new OWASP Top Ten, there are some carryovers from the previous list: injection, broken authentication and session management, cross-site scripting, security misconfiguration, sensitive data exposure, cross-site request forgery, and the use of known vulnerable components.

Some have been merged into new additions. "Missing function level access control," for example, has been merged with the new "broken access control" item, and "insecure direct object references" was merged into "insufficient attack protection." One previous risk—unvalidated redirects and forwards—was dropped entirely and replaced with unprotected APIs.

Here's a look at the major changes in the OWASP Top Ten, and what your application security team needs to know about the controversy surrounding the update. 

API risk

The proposed changes have received mixed reviews from the security community. "To a large extent, the changes make sense because the way that applications are put together in general has changed," said Mic Whitehorn-Gillam, senior security consultant at Secure Ideas, a security testing, training, and consulting company.

"[API protection] is more relevant today than it was in 2013 because of the need for the web applications to accommodate mobile applications."
—Mic Whitehorn-Gillam

Among the proposed changes is A10, "underprotected APIs." In their request for comments, the co-authors of the revamped Top Ten, Jeff Williams and Dave Wichers, explained the need for the change this way:

"Modern applications and APIs often involve rich client applications, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities. We include it here to help organizations focus on this major emerging exposure."

Adding APIs to the list recognizes the current threat landscape, maintained Stephen Gates, chief research intelligence analyst with Zenedge, a provider of cloud-based, AI-driven cybersecurity solutions.

"APIs are being utilized more and more for machine-to-machine-like communications, so the APIs are a rich attack surface for hackers to take advantage of."
—Stephen Gates

"It makes sense to call this out directly because the attackers are changing their tactics all the time and we need to recognize the risk that can be capitalized on with regard to APIs," Gates added.

But not everyone agrees that A10 belongs on the Top Ten list. Synopsys' Steven argues that unprotected APIs are a web services problem. "It's supposed to be a list of the top 10 vulnerability types for web applications, not web services," he said.

When mobile came along, he explained, the OWASP Foundation created a mobile Top Ten because, it said, a different tech stack, platform, architecture, and threat model created the need for a different Top Ten. "There's nothing in A10 that is a web application vulnerability," he argued. "It's a class of vulnerability to a different tech stack. It doesn't belong on the list."

Insufficient attack protection explained

Another proposed change—A7, insufficient attack protection—also has its critics. In their release notes for the new Top Ten, Williams and Wichers explained that the change was needed because the majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks.

"This new requirement means that applications need to detect, prevent, and respond to both manual and automated attacks," Williams wrote in a blog post for Contrast Security, where he is CTO.

"No longer will attackers be prompted with 'Invalid input, please try again,'" he continued. "Instead, anyone attempting attacks will have their attempts blocked and their account flagged."

He also touted how his company's product, Contrast Protect, meets the new requirement, which he helped create with Wichers, whose company, Aspect Security, is a customer of Contrast.

As with A10, critics found A7 out of place on a list of vulnerabilities, but the requirement also appeared to be steering companies toward using web application firewalls (WAFs) or runtime application self-protection (RASP)—the technology at the core of Contrast Protect.

James Kettle, head of research at PortSwigger Web Security, a web application security testing company, said, "There's a fair amount of evidence that it [A7] has been put in there as a cynical attempt by a company to sell more of their products."

"This is either a list of the top 10 web application security vulnerabilities or it's not. If it's just 10 things that vendors like to talk about so they can sell their products, then rename it."
—John Steven, Synopsys

Secure Ideas' Gillam disagreed. "The allegation that, perhaps, commercial interests were driving the inclusion of that item [A7] is very unsettling if that were the case," he said. "For me, I don't see that there is sufficient evidence to say for certain that is the case."

Comment draft rejected

WAFs may be another way to meet the requirements of A7. "I believe that web application firewall technology is simply required today," Gates said. "Web application firewall technology is designed to protect these applications, and oftentimes it has the OWASP Top Ten already built into it."

"There's a lot of folks out there that may not be happy with A7, but it makes a lot of sense for anybody having web applications facing the Internet to protect them with web application firewall technology."
—Stephen Gates

WAFs, too, have their critics. Steven explained that during his tenure at Cigital, an application and software security services company that was acquired by Synopsys, thousands of web applications were tested every month, many of them behind WAFs. "We found WAFs 100% ineffective at blocking attacks," he said.

All the furor over the proposed Top Ten has shaken up the process. At the OWASP summit held in June, RC1, the proposed Top Ten list that included the insufficient attack protection and API items was rejected and a new team led by Andrew van der Stock put in place.

A survey is being conducted to help determine up to two new items for the list, and a call for data has been reopened. A new target deadline has been established for November.

"There are a lot of positives. The new leadership, new transparency, and open call for data are valuable steps in the right direction."
—John Steven

Keep learning

Read more articles about: Security, Application Security
Twitter Twitter Facebook Watsapp Email share