How Well Does a Penetration Test Uncover OWASP Top 10 Flaws?

Last Updated on January 17, 2024

In our work with clients we sometimes encounter a misconception that performing an Application Vulnerability Assessment and/or a Penetration Test amounts to an assessment of a web application’s vulnerability to the OWASP Top 10 security flaws. This has never been the case, and with the 2013 Top 10 it’s even somewhat less so than for previous versions.
The scanning and manual testing of a web application that an Application VA/PT entails is extremely beneficial in uncovering vulnerabilities. But there’s no substitute for code review, audit and/or a Network VA/PT (to test the web server itself) to uncover some flaws.
If you want to see how your web application fares against the OWASP Top 10, what would you need in addition to a conventional VA/PT? Here’s a flaw-by-flaw breakdown:
A1 – Injection
The scanning and testing that goes with VA/PT may help determine whether some exploitable injection flaws exist. But testing cannot always reach all of the interpreters, and it can be difficult to determine if an attack was successful. Only checking the code can really determine if the application uses all its interpreters safely, so a source code scan or audit may be necessary to fully validate the application’s security.
A2 – Broken Authentication & Session Management
While most Authentication & Session Management flaws can be determined by scanning and manual testing of the application, some cannot. Verification of password encryption, server-side controls, and logging require an audit.
A3 – Cross-Site Scripting (XSS)
To ensure that an application is not vulnerable to XSS, all user-supplied input must be properly escaped before it is stored and/or returned to the user’s browser. Since there are multiple browser-side interpreters that might handle the script that is returned (JavaScript, ActiveX, Flash, Silverlight, etc.), automated testing is difficult. Only penetration testing and code review, along with automated scanning, can provide complete coverage.
A4 – Insecure Direct Object Reference
While penetration testing can uncover Direct Object Reference vulnerabilities, the tester may not find and/or may not be able to test all of them manually. Automated tools typically do not test object references, because they have no way to determine which require protection. Only a code review can verify that the protections on all object references are implemented correctly.
A5 – Security Misconfiguration
Security Misconfigurations cover a lot of areas, and an Application VA/PT will not test all of them. A Network VA/PT may help determine if any operating systems or server software are out of date. But only an audit can verify that a repeatable security configuration process is in place, that it addresses all of the necessary configuration guidelines, and that it is being followed.
A6 – Sensitive Data Exposure
A VA/PT of the application will be able to determine if sensitive data is being stored at all, and if it is being transmitted to the user securely. However, only a code review and an audit can determine if that data is being stored securely in the database, and if the communication between the application server and the database server is properly secured.
A7 – Missing Function Level Access Control
Testing Function Level Access Control can be completed manually during a penetration test. Browsing an application as a user with high privilege, and then attempting to access restricted areas of the application as a user with lower privilege, will uncover access control vulnerabilities pretty easily. Some testing tools can even automate this process. However, a code review can also uncover areas where authorization steps are not being followed in the application.
A8 – Cross-Site Request Forgery (CSRF)
CSRF flaws are relatively easy to detect during manual and/or automated testing by checking for the presence of a unique token to defeat CSRF attempts. However, we’ve found that some applications will ignore the unique token that is generated, and in some instances the proper utilization of the unique token can only be verified through a code review.
A9 – Using Components with Known Vulnerabilities
While manual testing may uncover components that are in use by an application, only a code review can guarantee that all of them are found. An audit can determine that procedures are in place to verify that all components are patched and/or updated regularly.
A10 – Unvalidated Redirects & Forwards
Automated tools can look for application parameters that appear to be part of a redirection or forward and test them, but only a code review can uncover all of them and ensure that they are verified against a whitelist.
In short: to really be sure that you’re protected from the OWASP Top 10 vulnerabilities, for just about all of them require a code review, audit and/or server-side testing in addition to a VA/PT would be beneficial, if not essential. To find out if these extra steps are important for your security posture (e.g., in regulated industries), contact Pivot Point Security.