OWASP’s new Top 10: Help for securing your web applications
Life itself is a risky proposition. There’s an almost endless number of ways to get hurt, sick, or killed before your time. But most people who manage those risks by avoiding the big ones — driving high or drunk, frequenting high-crime areas, smoking, living on a flood plain, eating nothing but fast food — also manage to live an average life span.
It’s a bit like that with software. There are thousands of criminal hackers out there looking to exploit any number of vulnerabilities in the digital code that runs everything from our smartphones and other devices to our smart homes, vehicles, and critical infrastructure.
But some threats are much more dangerous and/or exploitable than others. And one of the main missions of the Open Web Application Security Project — better known as OWASP — is to help everybody avoid the worst of those threats.
OWASP, coming up on its 20th anniversary on Dec. 1, is a nonprofit foundation that describes itself as an “open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.”
Over the past two decades it has grown to more than 200 local chapters with tens of thousands of members and its “projects, tools, documents, forums, and chapters are free and open to anyone interested in improving application security.”
But the project it’s probably most famous for is its iconic Top 10 list of the most critical risks to web applications. And that list was recently updated for the first time in four years. The update includes three new categories, plus some position shifts among those that remain.
Wait and see
Tanya Janca, founder and CEO of the learning platform We Hack Purple, volunteer leader of the OWASP Ottawa chapter from 2014 to 2019, and a frequent speaker at security conferences, gives the structure of the new list a mixed review.
“I like how they changed the wording on quite a few to add failures, such as ‘logging and monitoring failures’ to state that something is being done, but incorrectly,” she said. “But adding failures can be vague and difficult to fix. You can use tools to look for SSRF [server-side request forgery] and injections, but ‘software and data integrity failures’ is so vague, where would one start?”
And when it comes to the overall changes? “I’m not sure yet,” she said. “I need to see how others react to it. If it makes developers code more securely, I’ll think the changes are good. If it makes no difference, then I won’t.”
Jim Manico, CEO and application security architect at Manicode Security, a former OWASP global board member and a continuing OWASP volunteer, said he thinks the new list is “fantastic,” with the caveat that it is not meant to be a security standard. “It’s a great, relevant, unbiased, community-driven, data-driven list to help raise awareness to security issues for web developers today,” he said.
The OWASP website offers lots of detail on each vulnerability, including a description and why it is new to the list or has moved its position, specific examples, how to prevent it, and possible attack scenarios.
In brief, here is the list. All quotations, unless otherwise noted, are from the OWASP website.
Broken access control: This vulnerability moved from fifth to first place on the list with more occurrences in applications than any other category in the contributed dataset (more than 318,000).
As the name implies, it refers to a failure to limit access to data only to those who are authorized. It can “lead to unauthorized information disclosure, modification, or destruction of all data, or performing a business function outside the user’s limits.”
Cryptographic failures: This moved from third to second on the list, and it means that data is put at risk of being exposed or compromised because it’s not encrypted. Generally, data need to be encrypted both at rest and in transit. That is especially true of “passwords, credit card numbers, health records, personal information, and business secrets,” which can be governed by privacy laws or financial data protection regulations.
Injection: This dropped from second to third. It refers to vulnerabilities that allow attackers to inject malicious code into the network that then gets processed by an interpreter as part of a command or query, resulting in information from the database being sent to the attacker.
That can lead to data theft, data loss, loss of data integrity, denial of service, all the way up to full system compromise.
Insecure design: A new category for 2021, this refers to the digital version of designing a building with architectural flaws that could lead to everything from a roof leaking to a catastrophic foundation collapse.
OWASP notes that it’s important not to conflate design flaws with implementation flaws. “A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.”
Security misconfiguration: This moved from sixth to fifth place. “With more shifts into highly configurable software, it’s not surprising to see this category move up.”
Examples of this vulnerability include enabling or installing unnecessary features such as ports, services, pages, accounts, or privileges, or default accounts with passwords still enabled and unchanged.
Vulnerable and outdated components: This category rose from ninth to sixth. It should be obvious that organizations are vulnerable if they don’t know the versions of all components they use and whether the software is vulnerable, unsupported, or out-of-date. This includes the “operating system, web/application server, database management system, applications, APIs and all components, runtime environments, and libraries.”
The most effective way to start eliminating that vulnerability is to maintain a software inventory, otherwise known as a Bill of Materials. A common slogan at security conferences is, “you can’t protect what you don’t know you have.” And one of the best ways to maintain that inventory — given that the majority of the components in software are open source — is with an automated software composition analysis tool, which helps find those open source components and will let you know if there are known vulnerabilities or licensing conflicts in them.
Identification and authentication failure: This category, previously called broken authentication, dropped from second to seventh on the list. It refers to software defects that, among other things, permit automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. It also includes software that allows default, weak, or well-known passwords, such as Password1 or admin/admin, or that allows the use of weak or ineffective credential recovery and forgot-password processes, such as knowledge-based answers. It can also include software with missing or ineffective multifactor authentication.
Software and data integrity failure: This is a new category that focuses on making assumptions related to software updates or critical data without verifying their integrity.
One of the more recent examples of this is the autoupdate function in many applications where “updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations.”
Security logging and monitoring failures: This moved up one notch, from tenth to ninth. It elevates risk because “without logging and monitoring, breaches cannot be detected.”
Depending on the risk of the application, controls should include, at a minimum, ensuring that “all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.”
Server-side request forgery (SSRF): This made the Top 10 because “the security community members are telling us this is important, even though it’s not illustrated in the data at this time.”
This defect means that a web application “is fetching a remote resource without validating the user-supplied URL. It allows an attacker to persuade the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list.”
Addressing all those risks won’t make an organization bulletproof — nothing will. And OWASP doesn’t claim it will. But it would make it a much more difficult target.
Janca said addressing the Top 10 risks “would stop most attackers. Many of them are just failures to perform best practices or failure to perform them correctly,” she said. “If everyone did all the best practices, it would be much less profitable for cyber criminals.”
But she said virtually all the items on the list, while they are fundamental to security, aren’t simple or cheap.
“Access control can be quite onerous to get right and easy to mismanage,” she said in reference to the top item on the list. “And cryptography is incredibly challenging, especially key rotation. I think sometimes people forget that creating secure software is actually a very difficult task. It’s not just a button that software developers forget to press.”
Manico agrees. “We need to raise awareness that developers need to do a lot of work to get complicated access control requirements delivered, and that the typical DevOps approach — use security tools via automation to scan a lot — doesn’t address access control problems well.”
While the two think there is always room for improvement — Janca said she’d like to see OWASP do better at marketing, and Manico said he hopes the organization can release updates to its lists every three years instead of four — both are major fans of both the organization and the list.
“OWASP is likely the most influential organization regarding software security in the English-speaking world,” Janca said. “For AppSec folks like me, it’s even more important than NIST [National Institute of Standards and Technology] and other well-respected organizations that strive to help us secure technologies around the world.”
Manico is even more effusive. “OWASP is the center of the application security universe. I mean, the literal center of everything around application security,” he said.