OWASP Top 10 - 2013

O About OWASP Copyright and License Copyright © 2003 – 2013 The OWASP Foundation This document is released under the Creative Commons Attribution ShareAlike 3.0 license. For any reuse or distribution, you must make it clear to others the license terms of this work. Foreword Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our digital infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. We can no longer afford to tolerate relatively simple security problems like those presented in this OWASP Top 10. The goal of the Top 10 project is to raise awareness about application security by identifying some of the most critical risks facing organizations. The Top 10 project is referenced by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, FTC, and many more. This release of the OWASP Top 10 marks this project’s tenth anniversary of raising awareness of the importance of application security risks. The OWASP Top 10 was first released in 2003, with minor updates in 2004 and 2007. The 2010 version was revamped to prioritize by risk, not just prevalence. This 2013 edition follows the same approach. We encourage you to use the Top 10 to get your organization started with application security. Developers can learn from the mistakes of other organizations. Executives should start thinking about how to manage the risk that software applications create in their enterprise. In the long term, we encourage you to create an application security program that is compatible with your culture and technology. These programs come in all shapes and sizes, and you should avoid attempting to do everything prescribed by some process model. Instead, leverage your organization’s existing strengths to do and measure what works for you. We hope that the OWASP Top 10 is useful to your application security efforts. Please don’t hesitate to contact OWASP with your questions, comments, and ideas, either publicly to owasp-topten@lists.owasp.org or privately to dave.wichers@owasp.org. About OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. At OWASP you’ll find free and open … • Application security tools and standards • Complete books on application security testing, secure code development, and secure code review • Standard security controls and libraries • Local chapters worldwide • Cutting edge research • Extensive conferences worldwide • Mailing lists Learn more at: https://www.owasp.org All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in all of these areas. OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open source software projects, OWASP produces many types of materials in a collaborative, open way. The OWASP Foundation is the non-profit entity that ensures the project’s long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP Board, Global Committees, Chapter Leaders, Project Leaders, and project members. We support innovative security research with grants and infrastructure. Come join us! Welcome Welcome to the OWASP Top 10 2013! This update broadens one of the categories from the 2010 version to be more inclusive of common, important vulnerabilities, and reorders some of the others based on changing prevalence data. It also brings component security into the spotlight by creating a specific category for this risk, pulling it out of the obscurity of the fine print of the 2010 risk A6: Security Misconfiguration. The OWASP Top 10 for 2013 is based on 8 datasets from 7 firms that specialize in application security, including 4 consulting companies and 3 tool/SaaS vendors (1 static, 1 dynamic, and 1 with both). This data spans over 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact estimates. The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here. Warnings Don’t stop at 10. There are hundreds of issues that could affect the overall security of a web application as discussed in the OWASP Developer’s Guide and the OWASP Cheat Sheet Series. These are essential reading for anyone developing web applications. Guidance on how to effectively find vulnerabilities in web applications is provided in the OWASP Testing Guide and the OWASP Code Review Guide. Constant change. This Top 10 will continue to change. Even without changing a single line of your application’s code, you may become vulnerable as new flaws are discovered and attack methods are refined. Please review the advice at the end of the Top 10 in “What’s Next For Developers, Verifiers, and Organizations” for more information. Think positive. When you’re ready to stop chasing vulnerabilities and focus on establishing strong application security controls, OWASP has produced the Application Security Verification Standard (ASVS) as a guide to organizations and application reviewers on what to verify. Use tools wisely. Security vulnerabilities can be quite complex and buried in mountains of code. In many cases, the most cost-effective approach for finding and eliminating these weaknesses is human experts armed with good tools. Push left. Focus on making security an integral part of your culture throughout your development organization. Find out more in the Open Software Assurance Maturity Model (SAMM) and the Rugged Handbook. Attribution Thanks to Aspect Security for initiating, leading, and updating the OWASP Top 10 since its inception in 2003, and to its primary authors: Jeff Williams and Dave Wichers. We’d like to thank those organizations that contributed their vulnerability prevalence data to support the 2013 update:  Aspect Security – Statistics  HP – Statistics from both Fortify and WebInspect  Minded Security – Statistics  Softtek – Statistics  Trustwave, SpiderLabs – Statistics (See page 50)  Veracode – Statistics  WhiteHat Security Inc. – Statistics We would like to thank everyone who contributed to previous versions of the Top 10. Without these contributions, it wouldn’t be what it is today. We’d also like to thank those who contributed significant constructive comments and time reviewing this update to the Top 10:  Adam Baso (Wikimedia Foundation)  Mike Boberski (Booz Allen Hamilton)  Torsten Gigler  Neil Smithline – (MorphoTrust USA) For producing the wiki version of the Top 10, and also providing feedback And finally, we’d like to thank in advance all the translators out there that will translate this release of the Top 10 into numerous different languages, helping to make the OWASP Top 10 more accessible to the entire planet. I Introduction What Changed From 2010 to 2013? The threat landscape for applications security constantly changes. Key factors in this evolution are advances made by attackers, the release of new technologies with new weaknesses as well as more built in defenses, and the deployment of increasingly complex systems. To keep pace, we periodically update the OWASP Top 10. In this 2013 release, we made the following changes: 1) Broken Authentication and Session Management moved up in prevalence based on our data set. We believe this is probably because this area is being looked at harder, not because these issues are actually more prevalent. This caused Risks A2 and A3 to switch places. 2) Cross-Site Request Forgery (CSRF) moved down in prevalence based on our data set from 2010-A5 to 2013-A8. We believe this is because CSRF has been in the OWASP Top 10 for 6 years, and organizations and framework developers have focused on it enough to significantly reduce the number of CSRF vulnerabilities in real world applications. 3) We broadened Failure to Restrict URL Access from the 2010 OWASP Top 10 to be more inclusive: + 2010-A8: Failure to Restrict URL Access is now 2013-A7: Missing Function Level Access Control – to cover all of function level access control. There are many ways to specify which function is being accessed, not just the URL. 4) We merged and broadened 2010-A7 & 2010-A9 to CREATE: 2013-A6: Sensitive Data Exposure: – This new category was created by merging 2010-A7 – Insecure Cryptographic Storage & 2010-A9 - Insufficient Transport Layer Protection, plus adding browser side sensitive data risks as well. This new category covers sensitive data protection (other than access control which is covered by 2013-A4 and 2013-A7) from the moment sensitive data is provided by the user, sent to and stored within the application, and then sent back to the browser again. 5) We added: 2013-A9: Using Known Vulnerable Components: + This issue was mentioned as part of 2010-A6 – Security Misconfiguration, but now has a category of its own as the growth and depth of component based development has significantly increased the risk of using known vulnerable components. OWASP Top 10 – 2010 (Previous) OWASP Top 10 – 2013 (New) A1 – Injection A1 – Injection A3 – Broken Authentication and Session Management A2 – Broken Authentication and Session Management A2 – Cross-Site Scripting (XSS) A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A4 – Insecure Direct Object References A6 – Security Misconfiguration A5 – Security Misconfiguration A7 – Insecure Cryptographic Storage – Merged with A9  A6 – Sensitive Data Exposure A8 – Failure to Restrict URL Access – Broadened into  A7 – Missing Function Level Access Control A5 – Cross-Site Request Forgery (CSRF) A8 – Cross-Site Request Forgery (CSRF) A9 – Using Known Vulnerable Components A10 – Unvalidated Redirects and Forwards A10 – Unvalidated Redirects and Forwards A9 – Insufficient Transport Layer Protection Merged with 2010-A7 into new 2013-A6 Release Notes RN Weakness Attack Threat Agents Impact Weakness Attack Attack Vectors Security Weaknesses Technical Impacts Business Impacts Attack Impact Impact Asset Function Asset Weakness Control Control Control Weakness Security Controls Application Security Risks Risk References OWASP • OWASP Risk Rating Methodology • Article on Threat/Risk Modeling External • FAIR Information Risk Framework • Microsoft Threat Modeling (STRIDE and DREAD) What’s My Risk? The OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology. Only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference to your business. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise. We list Threat Agents as Application Specific, and Business Impacts as Application / Business Specific to indicate these are clearly dependent on the details about your application in your enterprise. The names of the risks in the Top 10 stem from the type of attack, the type of weakness, or the type of impact they cause. We chose names that accurately reflect the risks and, where possible, align with common terminology most likely to raise awareness. What Are Application Security Risks? Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention. Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine the overall risk. Threat Agents Attack Vectors Weakness Prevalence Weakness Detectability Technical Impacts Business Impacts App Specific Easy Widespread Easy Severe App / Business Specific Average Common Average Moderate Difficult Uncommon Difficult Minor Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. A1 – Injection Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities. A2 – Broken Authentication and Session Management XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. A3 – Cross-Site Scripting (XSS) A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. A4 – Insecure Direct Object References Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. A5 – Security Misconfiguration Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. A6 – Sensitive Data Exposure Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. A7 – Missing Function Level Access Control A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. A8 - Cross-Site Request Forgery (CSRF) Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. A9 - Using Components with Known Vulnerabilities Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. A10 – Unvalidated Redirects and Forwards OWASP Top 10 Application Security Risks – 2013 T10 Application Specific Exploitability EASY Prevalence COMMON Detectability AVERAGE Impact SEVERE Application / Business Specific Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators. Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources. Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. Consider the business value of the affected data and the platform running the interpreter. All data could be stolen, modified, or deleted. Could your reputation be harmed? Example Attack Scenarios Scenario #1: The application uses untrusted data in the construction of the following vulnerable SQL call: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)): Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'"); In both cases, the attacker modifies the ‘id’ parameter value in her browser to send: ' or '1'='1. For example: http://example.com/app/accountView?id=' or '1'='1 This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures. Am I Vulnerable To Injection? The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all