The Open Web Application Security Project (OWASP) is an open source application security community with the goal to improve the security of software. The OWASP Top 10 is an industry standard guideline that lists the most critical application security risks to help developers better secure the applications they design and deploy.
Since security risks are constantly evolving, the OWASP Top 10 list is revised periodically to reflect these changes. In the latest version of OWASP Top 10 released in 2017, some types of vulnerabilities which no longer represent a serious threat were replaced with ones most likely to pose a significant risk. An updated Top 10 is expected in 2021.
While the OWASP Top 10 is a great place to start securing applications, it certainly should not be considered as an end goal since some of the most-cited vulnerabilities didn’t make it into the OWASP Top 10 2017. To guard against software weakness, defenders need to look more broadly across their information-technology stack. This means IT security professionals need to focus across the entire software ecosys-tem and look beyond the ‘traditional’ sources of vulnerabilities.
Does the OWASP Top 10 cover all vulnerabilities?
Fortify’s Application Security Risk Report (2019) showed that 94% of tested applications had at least one security issue not covered by the OWASP Top 10. Furthermore, 61% of tested applications had at least one security issue deemed critical or high severity that was not covered by the OWASP Top 10. This report also analyzed 11,000 applications as mapped to OWASP Top 10 2017 categories.
What are the OWASP Top 10 (2017) categories?
Injection flaws can be introduced whenever an untrusted data source is sent to an interpreter. Examples are often found in SQL, LDAP, XPath or NoSQL dynamic database queries with user supplied input. Attackers inject code into the user input, tricking the query interpreter into executing malicious commands.
What Makes an Application Vulnerable to Injection Flaws?
- User-supplied data not being sufficiently validated
- Dynamic queries run without enough input sanitization
- Hostile data used within systems for malicious behavior
What’s the Impact of Injection Flaws?
- Compromise of the application or underlying host
- Exposure of sensitive data
- Loss of productivity, reputation, or revenue
How Can Fortify Help with Injection Flaws?
- If you are a developer: Fortify detects injection flaws and provides type-specific remediation advice
- If you are in QA or Operations: Fortify validates code at runtime for mitigating controls
- If you are in Operations: Fortify provides runtime logging and protection for Java and .NET injection attempts
A2: Broken Authentication
Broken authentication can be introduced when managing identity or session data in stateful applications. Examples are often found when registration, credential recovery, and API pathways are vulnerable to unexpired session tokens, brute forcing, or account enumeration. Attackers assume the identity of legitimate users, taking control of accounts and compromising data, processes, or systems.
What Makes an Application Vulnerable to Broken Authentication?
- Exposes, does not properly invalidate, or fails to rotate session IDs
- Does not align password policies with standards such as NIST 800-63B
- Lacks two-factor authentication (2FA) or permits automated attacks
What’s the Impact of Broken Authentication?
- User identity theft
- Loss of user trust
- Compromise of sensitive data
How Can Fortify Help?
- If you are developer: Fortify detects and recommends remediation for broken authentication issues
- If you are in QA or Operations: Fortify validates authentication and session management security dynamically
- If you are in Operations: Fortify instruments runtime monitoring for Java and .NET application events
A3: Sensitive Data Exposure
Sensitive data exposure issues can be introduced when applications access unencrypted data, particularly personally identifiable information (PII) and other regulated data types. Examples are often found when weak cryptographic cyphers are used in legacy applications, secure transport protocols are implemented incorrectly, or data-centric security is not in use. Attackers gain access to sensitive user data that gives them control in real life.
What Makes an Application Vulnerable Sensitive Data Exposure?
- Transmission of data in clear text via protocols such as HTTP, SMTP and FTP
- Sensitive data being stored, transmitted, or used unnecessarily in clear text
- Use of old, weak, or non-standards-based cryptographic algorithms
What’s the Impact of Sensitive Data Exposure?
- Compromise of regulated data (e.g. HIPAA or GDPR) resulting in fines
- Identity hijacking resulting in costs to scrub or monitor data
- Non-compliant status for privacy laws and regulations
How Can Fortify Help with Sensitive Data Exposure?
- If you are a developer: Fortify identifies sensitive data exposure and automates issue auditing
- If you are in QA or Operations: Fortify removes findings mitigated outside the application context with templating
- If you are in Operations: Fortify instruments logging and protection for applications in Java and .NET
A4: XML External Entities
XML External Entity issues can be introduced when an XML input containing a reference to an external entity is processed by a weakly configured parser. Examples are often found in applications that parse XML input from untrusted sources, when Document Type Definitions (DTDs) are enabled, or that use unpatched frameworks like SOAP 1.0. XML is everywhere—from SVG and image files to networking protocols and document formats such as PDF and RSS. Attackers reference external entities in XML input that results in processors exploited to extract data, execute code remotely, or impact network services.
What Makes an Application Vulnerable to XML External Entities?
- The application parses XML documents and processors have DTDs enabled
- Using SAML for SSO, SOAP prior to v1.2, or .NET Framework prior to v2.0
- The parser accepts untrusted sources or inserts untrusted XML data
What’s the Impact of XML External Entities?
- Theft of sensitive data
- Loading of attacker-controlled URL
- Denial of Service Attacks (DoS)
How Can Fortify Help with XML External Entities?
- If you are a developer: Fortify detects vulnerable XML parsers and recommends mitigating factors
- If you are in QA or Operations: Fortify automatically scans for vulnerable XML parsers and validates exploit payloads
- If you are in Operations: Fortify provides runtime logging and protection for issues in Java and .NET applications
A5: Broken Access Control
Access control issues can be introduced when code and environmental restrictions overlap incompletely or are defined in multiple places for similar functionality. Examples are often found when security-by-obscurity is broken through forceful browsing to restricted pages, or when the application defines complex methods for access control in multiple ways and locations. Attackers can compromise access boundaries to steal sensitive data or disrupt operations.
What Makes an Application Vulnerable to Broken Access Control?
- Ability to act as a user without login, or an admin when logged in as a user
- Manipulation of metadata or tokens for unauthorized or elevated privileges
- Byzantine, unenforced, or scattered access control logic
What’s the Impact from Broken Access Control?
- Unauthorized information disclosure or compromise of sensitive data
- Modification or destruction of data
- Takeover of site administration or users
How Can Fortify Help with Broken Access Control?
- If you are a developer: Fortify automates auditing and allows templating to remove issues mitigated elsewhere
- If you are in QA and Operations: Fortify agents detect hidden attack surface and broken access control systems
- If you are in Operations: Fortify instruments runtime access control logging for Java and .NET applications
A6: Security Misconfiguration
Security misconfiguration flaws can be introduced during the configuration of the application or its underlying environment. Misconfiguration can happen at any level of an application stack—from network services and application servers to containers and storage. Examples are often found in default accounts and configurations, "leaky" error messaging, or unpatched frameworks and services. Attackers can gain deployment information and access to privileged data to disrupt operations.
What Makes an Application Vulnerable to Security Misconfiguration?
- Unnecessarily enabled default ports and accounts or unchanged passwords
- Revealing stack trace or other messages in case of errors and exceptions
- Not appropriately hardening security for the risk posed by any part of the stack
What’s the Impact of Security Misconfiguration?
- Impact can vary from information disclosure to complete system compromise.
How Can Fortify Help with Security Misconfiguration?
- If you are a developer: Fortify identifies application dependencies and configuration files during scans
- If you are in QA and Operations: Fortify dynamically evaluates application and server configurations for issues
- If you are in Operations: Fortify provides open source analysis for reporting on environmental risks
A7: Cross-Site Scripting
What Makes an Application Vulnerable to Cross-Site Scripting (XSS)?
There are three forms of XSS, usually targeting user agents such as browsers:
- Reflected XSS: The application or API includes untrusted input in HTML output.
- Stored XSS: Non-sanitized code saved to disk is triggered later by user action
- DOM XSS: Applications, frameworks, and APIs that consume untrusted input
What’s the Impact of Cross-Site Scripting (XSS)?
- Takeover of the victim’s account in the application
- Retrieval of data from the target web application
- Modification of content on the page
How Can Fortify Help with Cross-Site Scripting (XSS)?
- If you are a developer: Fortify detects XSS vulnerabilities in code and predicts the likelihood of exploit
- If you are in QA and Operations: Fortify validates code dynamically for unsanitized inputs vulnerable to XSS
- If you are in Operations: Fortify provides logging for Java and .NET events including unauthorized redirect
A8: Insecure Deserialization
Unsafe deserialization flaws can be introduced when languages and frameworks allow untrusted serialized data to be expanded into an object, often when web applications are communicating user or saving application state. Examples are often found when developers place no restrictions on methods that can self-execute during the deserialization process. Attackers leverage these "gadget chains" called outside of the application logic leverage to remotely execute code, deny service, or gain unauthorized access.
What Makes an Application Vulnerable to Insecure Deserialization?
- The application deserializes data from untrusted sources
- The application does not verify the source or contents before deserialization
- Acceptable classes are not whitelisted to avoid unnecessary gadget exposure
What’s the Impact of Insecure Deserialization?
- These flaws can lead to remote code execution attacks, one of the most serious attacks possible.
How Can Fortify Help with Insecure Deserialization?
- If you are a developer: Fortify detects vulnerabilities in source code and provides component analysis
- If you are in QA and Operations: Fortify instruments dynamically running applications to validate attack vectors
- If you are in Operations: Fortify instruments logging for Java and .NET events including deserialization
A9: Using Components with Known Vulnerabilities
These flaws can be introduced when open source or third-party frameworks and libraries are introduced into an application and run with the same privileges. Examples are often found where component-based development results in a lack of understanding of the risks associated with dependencies and components or systems are difficult or impossible to patch. Attackers have leveraged vulnerable components for some of the largest breaches in history, though vulnerabilities can range from application compromise to remote code execution.
What Makes an Application Vulnerable to Open Source or Third-party Frameworks and Libraries?
- These can be accidental (e.g. coding error) or intentional (e.g. backdoored component).
- The application or environment uses unpatched or outdated components
- Lack of scanning for vulnerabilities in third-party code or nested dependencies
- Unavailable component inventories or ignored security bulletins
What’s the Impact of Using Components with Known Vulnerabilities?
- While some known vulnerabilities lead to only minor impacts, some of the largest known breaches, such as Heartbleed and Shellshock, have relied on exploiting known vulnerabilities in shared components. Using components with known code vulnerabilities can result in remote code execution on the affected server, giving the attacker total control of the machine.
How Can Fortify Help with Open Source Security?
- If you are developer: Fortify provides software component analysis via Sonatype integrations
- If you are in QA and Operations: Fortify automates dynamic validation of known vulnerabilities at runtime
- If you are in Operations: Fortify instruments logging and protection for Java and .NET application components
A10: Insufficient Logging and Monitoring
Insufficient logging and monitoring flaws can be introduced when attack vectors or application misbehavior is not well understood or best practices of monitoring for indicators of compromise are not followed. Examples are often found in legacy systems without logging capabilities, when logs of application penetration testing go unexamined, or when logs do not provide sufficient detail for understanding what attackers did. Attackers rely on an average of around 200 days for detection that is typically discovered externally to establish persistence and pivot to additional vulnerable systems.
What Makes an Application Vulnerable to Insufficient Logging and Monitoring?
- Warnings and errors generate no, inadequate, or unclear log messages
- Logs are stored locally without tamper controls and/or are unmonitored
- Alert thresholds and response processes are insufficient or result in no action
What’s the Impact of Insufficient Logging and Monitoring?
- Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploits. Attackers may establish persistence, backdooring applications and operating systems, stealing data, or otherwise gaining unnoticed, unauthorized control of systems. If security critical information is not recorded or stored appropriately, there will be no trail for forensic analysis to discover the source of attack. Understanding that there is a problem at all may become more difficult, or impossible, if the attacker maintains control of logging capabilities.
How Can Fortify Help with Insufficient Logging and Monitoring?
- If you are developer: Fortify scans logging capabilities in applications and APIs for vulnerabilities
- If you are in QA and Operations: Fortify dynamic scans produce application logs for sufficiency review, like pen testing
- If you are in Operations: Fortify instruments logging and protection for Java and .NET applications
For additional information, check out our Developer’s Guide to the OWASP Top 10 2017 with additional information on How Does it Work? And How to Stop It? for each category. You can also watch “What is the OWASP Top 10?” in our AppSec 101 series on the Fortify Unplugged YouTube channel.
Want to see how Fortify can help your organization? Start Your Free 15-Day Trial of Fortify on Demand Now