OWASP Top 10: What are Injection Flaws?

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

OWASP Top 10: What is 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

OWASP Top 10: What is 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

OWASP Top 10: What are 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

OWASP Top 10: What is 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

OWASP Top 10: What is 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

OWASP Top 10: What is Cross-Site Scripting?

Cross-Site Scripting (XSS) flaws can be introduced when untrusted, un-sanitized user input is executed as part of the HTML, or when users can be influenced to interact with malicious links. Examples are often found when familiar code constructs from languages such as JavaScript or Flash are accepted from untrusted sources or stored for later display by another user agent. Attackers can perform remote code execution on the user's machine, steal credentials, or deliver malware from redirect sites. 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

OWASP Top 10: What is 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

OWASP Top 10: 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

OWASP Top 10: What is 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

What is OWASP Top 10?

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?

A1: Injection

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

Cross-Site Scripting (XSS) flaws can be introduced when untrusted, un-sanitized user input is executed as part of the HTML, or when users can be influenced to interact with malicious links. Examples are often found when familiar code constructs from languages such as JavaScript or Flash are accepted from untrusted sources or stored for later display by another user agent. Attackers can perform remote code execution on the user's machine, steal credentials, or deliver malware from redirect sites.

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

Your browser is not supported

Industry Solutions

Enterprise Solutions