Open Web Application Security Project (OWASP) Top 10 was created to show the critical risks facing applications, was first released in 2003, and has been a foundational guide in creating an application security program to incorporating security into the software development lifecycle (SDLC).
But as application security has developed and the security industry itself has evolved, the standard for applications has as well.
Let’s take a look at OWASP Top 10, OWASP testing guide, and the Application Security Verification Standard (ASVS) to see what place each may have in your application security program.
OWASP Top 10 (2017) vs OWASP Top 10 (2013)
A few items left were removed from the OWASP Top 10 2013 version to the 2017 version, such as cross-site request forgery and the unvalidated redirects and forwards. Here is a list of OWASP Top 10 Application Risks (2017):
- Injection
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting
- Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
The fact that cross-site request forgery (CSRF) was struck from this list as its own entity in 2017 is quite a significant issue. For example, NETGEAR home router, not too long ago, saw a simple asterisk, a wildcard injection where you could dump or drop all the firewall rules configured in the router from the internet. CSRF is a big deal. There may even be more value in testing for CSRF rather than cross-site scripting, but overall this is community-driven. We’re possibly seeing fewer CSRF issues, and the community is taking these things into account over time.
We’re seeing the evolution of these vulnerabilities, and we’re helping to build how we're looking at the security of these applications.
OWASP Testing Guide
The OWASP Top 10 is essentially a list of vulnerability categories. But how do we find them? Then, what do we do about them?
The security community created the OWASP testing guide as a formalized methodology. Independent testers, consultancies, and other groups have been pushing testing methodologies since the dawn of hacking as a culture but there was no real consensus or vetted process until this testing guide. The testing guide also offers developers and application owners insight into what attackers look for which then also helps pen testers discover those vulnerabilities.
There is some high-level theory here involved in what the testing guide lays out. It's still very specific into how you may test for cross-site scripting, for example. It explains quite well what cross-site scripting is. They give you some rudimentary examples of cross-site scripting. While some attacks aren’t as rudimentary, the testing guide gives us a baseline for looking for those specific vulnerabilities in an application, how to prevent it from being introduced into the environment during design and build phases, and ultimately how it can be tested for at execution once the applications are actually live.
Now, there are some things that don't necessarily get tested by just using the OWASP Top 10. Some things typically overlooked are things such as file upload, local file inclusion attacks. There certainly are weaknesses in every methodology no doubt, but the general idea is to make sure that you get good coverage with what you're looking at through the testing guide. Learn how to apply OWASP with your internal testing team.
The Application Security Verification Standard (ASVS)
How did the ASVS evolve from the testing guide?
The testing guide provides developers with some insight into the vulnerabilities, and it provides testers at all levels of the SDLC with guidelines for testing; however, the ASVS takes us a step further.
The OWASP ASVS really takes the application's risk profile into account so it allows us to prioritize what we're looking for. It allows us to start to have a workflow and metrics to determine how deep our testing should go, what the requirements will be for testing, and here we start to see that the development of a more P-Test (penetration test) like standard. The ideal is for the ASVS to be used by organizations who are publishing these applications, application owners and developers are using them again to have a more thorough understanding of how to protect their applications with the proper standard, and then it also allows those organizations, when they're looking for third party testers, to hold those third parties accountable to these standards.
Security can sometimes be like the Wild Wild West. It still feels like that at times even though we're becoming more formalized, more professional and official. But really the ASVS and P-Test are the first times that we're starting to see true standards wrapped around not just how to test a specific issue but how to develop an application’s security, how to evaluate the architecture properly, how to design security components and controls into your applications and then how to make sure that you're testing it both internally and with a third-party partner in a rational and secure manner so that you're making sure that you're meeting these specific levels that applications require.
We want to make sure we’re doing things the same way instead doing annual penetration tests or application assessments and doing them differently three years in a row. How then would you have any real verification or confidence in the results? The ASVS gives us that. Consistency in testing is critical.
The Difference Between OWASP Top 10 and ASVS
These categories that you're seeing in the ASVS are very similar to what we were seeing with the testing guide, but the difference is that the ASVS broader. This is more based around different components throughout the SDLC from design to penetration testing and even the go-live use date.
We are seeing a more conceptual methodology that really is driving how we build this application out. We are seeing things like threat modeling built into the design and architecture pieces of the build process. We're seeing actual requirements around how the authentication verification happens within an application.
We recommend readers go to the OWASP page about the ASVS because in version four, one of the biggest, most significant changes was implementation of some NIST requirements that regulate how authentication verification should happen in, we believe, level two and three applications. This is significant because we're seeing some kind of conversation around push back, that we don't necessarily need such stringent expectations.
But again, the community came together and decided that we want to build a standard and part of the purpose of the ASVS is to start seeing standardized expectations for authentication verification across organizations like NIST or OWASP's recommendations. It's a convergence of this latest evolution in application security where we're trying to build a standard for everybody who's involved in developing an application and its security.
OWASP is a great program in that it is community-based, community-created, and free without an agenda other than security.
Testing Your Applications
The Top 10, testing guide, and ASVS each has its relevant place in your security processes, but it's also important to recognize the strengths, the weaknesses, and the limitations of each.
You must layer controls; you must layer mechanisms of protection on top of each other in order to truly reduce risk.
Get your web application assessment sample report to see how you can turn OWASP guidelines into actionable next steps.
For further reading, check out this beginner's guide to vulnerability scanning, the 7 application assessment components you don't want to miss in your next review, or pretty much everything you need to know about penetration testing.
Or read the next article in our OWASP series on using OWASP in your application's software development lifecycle.
