Stack Trace In Error Message

V7 - Error Logging

Stack Trace in Error Message

POC

1. Send various invalid data input or insert illegal characters to the URL or the HTTP request.

2. Observe the stack trace revealed in the error message

Impact

Low

Likelihood

Low

Likelihood

Low
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.
V5 - Validation / Sanitization

The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding. This weakness leads to almost all of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

Ensure that a verified application satisfies the following high-level requirements:

• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.

• Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.

• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.
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
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.

V7 - Error Logging

POC

1. Send various invalid data input or insert illegal characters to the URL or the HTTP request.

2. Observe the stack trace revealed in the error message

Impact

Low

Likelihood

Low

Likelihood

Low

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.

V5 - Validation / Sanitization

The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding. This weakness leads to almost all of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

Ensure that a verified application satisfies the following high-level requirements:

• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.

• Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.

• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.

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

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

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.

V7 - Error Logging

Non Customized Error Messages (Error Message Reveals Internal IP Address/Underlying Technology)

V7 - Error Logging

Stack Trace in Error Message

V7 - Error Logging

Unhandled Error Messages - SQL Queries Revealed

V7 - Error Logging

Visible Detailed Error/Debug Page

V2 - Authentication

Authentication Bypass

V2 - Authentication

2-Factor Authentication (2FA) Bypass

V2 - Authentication

CAPTCHA Bypass - X-Forwarded-For

V2 - Authentication

Lack of Password Confirmation

V2 - Authentication

Lack of Verification Email

V2 - Authentication

Mail Bombing in the Contact Form

V2 - Authentication

Missing brute-force protection for two-factor authentication

V2 - Authentication

No Rate Limiting on a Form

V2 - Authentication

Password Cracking for Common/Weak Passwords when Password Policy is Weak

V2 - Authentication

Username/Email Address Enumeration

V2 - Authentication

Using Default Credentials

V2 - Authentication

Weak 2FA Implementation

V2 - Authentication

Weak Password Policy

V2 - Authentication

Weak Registration Implementation over HTTP

V3 - Session management

Insecure Storage of JWT Token

V3 - Session management

JWT token over URL (GET method)

V3 - Session management

Old Session do not invalidate after logout

V3 - Session management

Old Session do not invalidate after password change

V3 - Session management

Password Link Expiration Errors

V3 - Session management

Password Reset Token Sent Over HTTP

V3 - Session management

Session Fixation for Concurrent Sessions

V3 - Session management

Session Fixation for the Same Account

V3 - Session management

Session Timeout is Too Long

V3 - Session management

Session token predictable / low entropy

V4 - Access control

Account takeover via "Forgot your password" functionality

V4 - Access control

Admin panel publicly accessible

V4 - Access control

Admin panel takeover

V4 - Access control

AWS bucket misconfiguration

V4 - Access control

Critically Sensitive Data - Password Disclosure

V4 - Access control

Critically Sensitive Data - Private API Keys

V4 - Access control

CSRF

V4 - Access control

Database Management System (DBMS) Misconfiguration:Excessively Privileged User / DBA

V4 - Access control

Directory Listing Enabled

V4 - Access control

EXIF Geolocation Data Not Stripped From Uploaded Images - User Enumeration

V4 - Access control

Insecure crossdomain.xml policy

V4 - Access control

OAuth Account Takeover

V4 - Access control

OAuth Insecure Redirect URI

V4 - Access control

OAuth Missing/Broken State Parameter

V4 - Access control

Sensitive Token in URL

V4 - Access control

Token Leakage via Referer

V4 - Access control

Weak Password Reset Implementation - Token Leakage via Host Header Poisoning

V5 - Validation / Sanitization

Blind SQL injection

V5 - Validation / Sanitization

Clickjacking

V5 - Validation / Sanitization

Command Injection

V5 - Validation / Sanitization

Cross Site Script Inclusion (XSSI)

V5 - Validation / Sanitization

CSRF/URL-Based XSS

V5 - Validation / Sanitization

CSS injection

V5 - Validation / Sanitization

CSV Injection

V5 - Validation / Sanitization

DOM-Based XSS

V5 - Validation / Sanitization

Flash-Based XSS

V5 - Validation / Sanitization

HTML injection

V5 - Validation / Sanitization

HTTP Parameter Pollution to XSS

V5 - Validation / Sanitization

HTTP Request Smuggling

V5 - Validation / Sanitization

HTTP Response Splitting (CRLF)

V5 - Validation / Sanitization

iframe Injection

V5 - Validation / Sanitization

LDAP injection

V5 - Validation / Sanitization

Local File Inclusion

V5 - Validation / Sanitization

OOB (Out of Band) XXE

V5 - Validation / Sanitization

Open Redirect

V5 - Validation / Sanitization

Reflected File Download (RFD)

V5 - Validation / Sanitization

Reflected Self-XSS

V5 - Validation / Sanitization

Reflected XSS

V5 - Validation / Sanitization

Reflected XSS - WAF bypass

V5 - Validation / Sanitization

Remote Code Execution

V5 - Validation / Sanitization

Remote File Inclusion

V5 - Validation / Sanitization

Rosetta Flash

V5 - Validation / Sanitization

Server Side Template Injection

V5 - Validation / Sanitization

Server Side Template Injection (SSTI) in Flask

V5 - Validation / Sanitization

SQL Injection

V5 - Validation / Sanitization

SSI Injection

V5 - Validation / Sanitization

SSRF

V5 - Validation / Sanitization

Stored XSS

V5 - Validation / Sanitization

Tabnabbing

V5 - Validation / Sanitization

TRACE Method XSS - Cross-Site Tracing (XST)

V5 - Validation / Sanitization

Universal (UXSS) XSS

V5 - Validation / Sanitization

WAF Bypass

V5 - Validation / Sanitization

XSS via Referer

V5 - Validation / Sanitization

XXE

V6 - Cryptography

Weak TLS configuration - Padding Oracle

V9 - Communications

Weak TLS configuration - Sensitive Information Sent via Unencrypted Channels

V9 - Communications

Weak TLS configuration - weak ciphers

V10 - Malicious Code

Subdomain Takeover

V11 - Business Logic

DoS - App Crash

V11 - Business Logic

File Upload - No Size Limit

V11 - Business Logic

Horizontal Privilege Escalation

V11 - Business Logic

Negative Bank Transaction

V11 - Business Logic

No Antivirus - EICAR file Upload

V11 - Business Logic

Unrestricted File Upload - File Extension Filter Bypass

V11 - Business Logic

Vertical Privilege Escalation

V14 - Config

CORS (Cross-Origin Resource Sharing)

V14 - Config

CORS (Cross-Origin Resource Sharing) Vulnerability Leaking Sensitive Data

V14 - Config

Email Spoofing to Inbox due to Missing or Misconfigured DMARC on Email Domain

V14 - Config

Enabled HTTP PUT method leads to create malicious file on the server

V14 - Config

Lack of Security Headers

V14 - Config

Mail Server Misconfiguration - Missing or Misconfigured SPF and/or DKIM

V14 - Config

Mail Server Misconfiguration - No Spoofing Protection on Email Domain

V14 - Config

Misconfigured DNS - Missing Certification Authority Authorization (CAA) Record

V14 - Config

Misconfigured DNS - Zone Transfer

V14 - Config

Missing Strict Transport Security Header (HSTS)

V14 - Config

Missing X-Frame-Options Header

V14 - Config

Out-Of-Date Component in use

V14 - Config

Server Banner Disclosure

V14 - Config

Weak Content-Security-Policy

V14 - Config

Webserver Default Page Reveals Internal Info (Nginx, IIS)

INF1 - Network

Weak or Default Credentials for Jboss or Wildfly

INF1 - Network

Information Disclosure SMB

INF1 - Network

Weak or Default Credentials for Tomcat

INF1 - Network

Weak or Default Credentials in Use

INF1 - Network

Information Disclosure SMB not Required

INF1 - Network

LDAP Anonymous Bind

INF1 - Network

Weak Domain Passwords

INF1 - Network

Weak or Default Jenkins Credentials

INF1 - Network

Cached LSA Secrets in Cleartext

INF1 - Network

Anonymous SMB File Shares

INF1 - Network

Reusing Local Administrator Passwords

INF1 - Network

NetBIOS Poisoning

INF1 - Network

Anonymous FTP Servers

INF1 - Network

NULL Sessions on Domain Controller

INF1 - Network

Jenkins Script Console Access

INF1 - Network

LLMNR Poisoning

INF1 - Network

Lack of Authentication Controls for Jenkins

The 25x Remediation Gap: See how elite security teams resolve risks in 10 days vs. 249

State of Pentesting Report

Services Overview

By Use Case

Solutions Overview

The Responsible AI Imperative

Pentesting Pulse Report

State of Pentesting Report

Services Overview

By Use Case

Solutions Overview

The Responsible AI Imperative

Pentesting Pulse Report

The 25x Remediation Gap: See how elite security teams resolve risks in 10 days vs. 249

Your vulnerability dictionary!

Stack Trace in Error Message

POC

Impact

Likelihood

Likelihood

V7 - Error Logging

Stack Trace in Error Message

POC

Impact

Likelihood

Likelihood

V2 - Authentication

V3 - Session management

V4 - Access control

V5 - Validation / Sanitization

V6 - Cryptography

V8 - Data Protection

V9 - Communications

V10 - Malicious Code

V11 - Business Logic

V12 - Files Resources

V13 - API

V14 - Config

INF1 - Network

V7 - Error Logging

V7 - Error Logging

V7 - Error Logging

V7 - Error Logging

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V2 - Authentication

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V3 - Session management

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control

V4 - Access control