This Wiki is a unique database with vulnerability Proof of Concepts to act as a resource for pentesters. The findings are categorized by the OWASP ASVS category.
Import CSV with the following contents:
Customer,Another
=2+5+cmd|' /C calc'!A0,=2+5+cmd|' /C calc'!A0
Download the file to pop-up calculator on Windows
Low
Low
Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.
When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST 800-63 considers usernames and knowledge based authentication (KBA) as public information, SMS and email notifications as "restricted" authenticator types , and passwords as pre-breached. This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls always have been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on.
Of all the sections in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that's perfectly okay. We have to start the transition to a post-password future now.
One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or device interacting with it. Session management changes a stateless protocol to stateful, which is critical for differentiating different users or devices.
Ensure that a verified application satisfies the following high-level session management requirements:
As previously noted, these requirements have been adapted to be a compliant subset of selected NIST 800-63b controls, focused around common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory NIST 800-63b requirements.
Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high level requirements:
• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata is protected from replay or tampering.
Ensure that a verified application satisfies the following high level requirements:
• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed
The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.
High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:
• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.
It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.
Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.
Ensure that a verified application satisfies the following high level data protection requirements:
• Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: Data should be available to authorized users as required.
Ensure that a verified application satisfies the following high level requirements:
• TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
• Deprecated or known insecure algorithms and ciphers are disabled.
Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective.
Ensure that code satisfies the following high level requirements:
• Malicious activity is handled securely and properly to not affect the rest of the application.
• Does not have time bombs or other time-based attacks.
• Does not "phone home" to malicious or unauthorized destinations.
• Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.
Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
Ensure that a verified application satisfies the following high level requirements:
• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
Ensure that a verified application satisfies the following high level requirements:
• Untrusted file data should be handled accordingly and in a secure manner.
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.
Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has:
• Adequate authentication, session management and authorization of all web services.
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API
Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns.
Ensure that a verified application has:
• A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration.
Import CSV with the following contents:
Customer,Another
=2+5+cmd|' /C calc'!A0,=2+5+cmd|' /C calc'!A0
Download the file to pop-up calculator on Windows
Low
Low
Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.
When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST 800-63 considers usernames and knowledge based authentication (KBA) as public information, SMS and email notifications as "restricted" authenticator types , and passwords as pre-breached. This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls always have been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on.
Of all the sections in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that's perfectly okay. We have to start the transition to a post-password future now.
One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or device interacting with it. Session management changes a stateless protocol to stateful, which is critical for differentiating different users or devices.
Ensure that a verified application satisfies the following high-level session management requirements:
As previously noted, these requirements have been adapted to be a compliant subset of selected NIST 800-63b controls, focused around common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory NIST 800-63b requirements.
Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high level requirements:
• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata is protected from replay or tampering.
Ensure that a verified application satisfies the following high level requirements:
• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed
The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.
High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:
• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.
It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.
Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.
Ensure that a verified application satisfies the following high level data protection requirements:
• Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: Data should be available to authorized users as required.
Ensure that a verified application satisfies the following high level requirements:
• TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
• Deprecated or known insecure algorithms and ciphers are disabled.
Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective.
Ensure that code satisfies the following high level requirements:
• Malicious activity is handled securely and properly to not affect the rest of the application.
• Does not have time bombs or other time-based attacks.
• Does not "phone home" to malicious or unauthorized destinations.
• Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.
Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
Ensure that a verified application satisfies the following high level requirements:
• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
Ensure that a verified application satisfies the following high level requirements:
• Untrusted file data should be handled accordingly and in a secure manner.
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.
Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has:
• Adequate authentication, session management and authorization of all web services.
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API
Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns.
Ensure that a verified application has:
• A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration.
