The “OWASP Top 10” list of the most critical web application security risks is widely used as a basis for application security testing and as high-level guidance for assessing risks and prioritizing remediation of vulnerabilities. Recently, for the first time since 2013, OWASP revised the list.
The New OWASP Top Ten
Three “new” vulnerabilities were added to the Top 10 for 2017, two vulnerabilities from the 2013 list were rolled into one, and two vulnerabilities were dropped from the list (not without controversy). OWASP also made some minor updates to the attack scenarios.
Here is a quick rundown of the new OWASP Top Ten 2017 list:
Injection attacks (primarily via SQL, LDAP or operating system vectors) continue to top the charts, as many applications are still vulnerable to these high-risk attacks that frequently result in data breaches. Many of the penetration tests I personally have conducted recently have turned up this vulnerability in a wide range of applications.
This vulnerability kept its position from 2013, but its title was simplified. It still pertains to loopholes in username, password and session management functions; e.g., session hijacking.
A3:2017—Sensitive Data Exposure
This issue moved up from #6 in 2013, due to an increasing number of attacks targeting it. Many applications continue to store sensitive data as clear text, and/or failing to apply security directives or headers effectively.
A4:2017—XML External Entities (XEE)
Here we find the first of the new entries for 2017. OWASP included XEE because of its greatly increased relevance as more applications use web services. Its focus is on issues with older or misconfigured XML parsers and usage of the SOAP framework.
A5:2017—Broken Access Control
The new #5 reflects the merger of #4 (Insecure Direct Object References) and #7 (Missing Function Level Access Control) from 2013. Personally, I like this change because it puts focus on the bigger issue of access control vulnerabilities (e.g., privilege escalation, cross-origin resource sharing, misconfigurations, etc.) instead of on specific aspects of it.
Down from #5 in 2013, the scope of the vulnerability remains similarly broad-based: misconfigured application servers, misconfigured security settings in the application framework, and so on. OWASP also put strong emphasis on cloud service misconfigurations, which have resulted in so many high-profile data breaches as applications move to cloud environments.
Though it’s been bumped down from #3 to #7 for 2017, XSS remains the second most prevalent issue among web applications—found in two-thirds of applications tested, according to OWASP. The range of XSS attacks on users can result in exfiltration of data, installation of malware and even complete account compromise. Code review remains the best way to identify specific XSS vulnerabilities in applications.
This is a new addition to the Top 10, by popular demand of the user community. Leveraging application classes that can change behavior during or after deserialization, these flaws can permit remote code execution or manipulation/tampering of sensitive data on the affected platforms.
A9:2017—Using Components with Known Vulnerabilities
Holding on at #9 from the 2013 list, high-profile attacks targeting vulnerable, unsupported or out-of-date components continue unabated. The growing use of components and APIs can complicate finding these vulnerabilities and keeping third-party code up-to-date. As OWASP puts it: “Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.”
A10:2017—Insufficient Logging and Monitoring
Last but not least for 2017 is this new entry, introduced based on community feedback, which focuses on issues with application logging of key activities like logins, failed logins, warnings, high-value transactions, etc. It also covers issues around storing and protecting log data from tampering/misuse.
Gone from the 2017 list are the former A10 (Unvalidated Redirects and Forwards, which now affects only about 8% of applications), and the fearful former A8, Cross-Site Request Forgery (CSRF).
The rationale for dropping CSRF is that many modern programming language frameworks offer “built-in” defenses against CSRF by default, so that its prevalence has dropped below 5% of applications. However, CSRF vulnerabilities still pose high risks and new flaws continue to surface regularly (e.g., a newly discovered, critical flaw in the popular phpMyAdmin application).
To defend against OWASP Top 10 flaws, developers need to establish and use repeatable processes and security controls, security testers need to establish continuous application security testing, and application managers/owners need to take charge of the full application lifecycle from a security perspective. Further, the business as a whole needs to have an application security program in place.
To tap into expert guidance to optimize your application security program, policy, procedures and DevOps pipeline to reduce risks to your business and its customers, contact Pivot Point Security.