The OWASP Top Ten 2017 Release Candidate (RC) has been announced and is available for comment. When the Top Ten RC was initially broadcast through the OWASP leaders mailing list by Dave Wichers, project leader of the Top Ten, both positive and negative reactions began to flow. But one specific item in the list drew most of the controversy: A7: Insufficient Attack Protection.
The OWASP Top Ten has become the standard for classifying many vulnerabilities, and its relevance for application security is demonstrated by its use by vendors as a guideline within their products. From the makers of bug bounty portals to vulnerability scanners, vendors use the Top Ten as a way to classify application vulnerabilities they discover. The changes in A7 will affect many of these products, so the mixed reactions come as no surprise.
So what exactly is expected in the latest Top Ten, and how will changes impact your application security team? Here are the key changes you need to know.
API changes go beyond validation
With A7, APIs should have more than just input validation capabilities—they must block exploit attempts and log and detect potential attacks. So how does the Top Ten team conclude that an item is an application security risk? Initial data is based on submitted data from various sources, which is later analyzed by the team.
Many complaints around A7 concern the lack of data to support it. However, the Top Ten team did have a call for data in May last year, announced through the project’s and leaders' mailing lists and other social media channels. One major challenge in creating such a document is being able to have enough representative data to conclude and include the right vulnerabilities.
The data can be found here and is all open for review. Again, this is the time for comment and discussion. If your organization does not agree with any of the items, join the mailing list and kick off the discussion. This is the time to do so, before the document is finalized.
Complying with A7 will be a big challenge for many organizations' app sec teams. If complying with vulnerabilities such as cross-site scripting and SQL injection is complex, A7 will be even more challenging to put into effect, unless third-party tools such as WAFs or RASP are implemented within the architecture to work as a defense layer. But, in addition, opponents to the Top Ten A7 accuse the project leaders of having ulterior motives for this decision.
Protecting the API shifts left
Another new item is A10: Underprotected APIs. With the rise of mobile apps, this is a welcome addition. Many client applications do not communicate in the traditional architecture, talking directly to a database. Instead, most talk to an API. Protecting the API must be a priority for app sec teams starting early in the development cycle. Developer teams must understand that calling the AP—even when IP addresses are whitelisted—is obsolete at a time when hackers use attack proxies capable of changing the request parameters, including those sent to the API. This item overlaps with A7 in many ways.
"Insecure Direct Object References" and "Missing Function Level Access Control" have been merged into one item: A4: Broken Access Control. Some of the feedback received through the mailing list observed that the "separation of these two was kind-of artificial/arbitrary." Commenter's note: "It will be much easier to explain both aspects of this risk in one training segment rather than split across two."
For the most part, the new version does not contain significant changes beyond those related to APIs. But it's certain that app sec teams will need to pay more attention to the issues around adding unprotected APIs to apps. You must know how to develop and protect against the vulnerabilities that can arise when applications and systems communicate with each other.
Application security takes a village
One thing you must understand about OWASP projects is that they are managed independently, by volunteers. OWASP itself does not own any projects; the leaders do, and they follow the code of conduct described in the OWASP Project handbook and guidelines. OWASP projects are quite different from many open-source initiatives, in that they are are free to be managed, created, and produced at the project leader's pace.
Thus, it is up to project leaders to make major decisions regarding their projects' development. That is what the team behind the OWASP Top 10 has done. And keep in mind that the RC phase means that the final version is still being revised, so comments received during this phase could influence the final outcome of the project.
Join the discussion
Discussion around A7 of the Top Ten will continue during the OWASP Summit in London in June. Wichers will be present during these working sessions to discuss each item in the list, and the collected data—including yours. Can't make it? You can also attend the sessions remotely, at no cost. If you want to influence the outcome of the final release, log on.
Share your thoughts on this RC in the comments below.
Image credit: Flickr
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
