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.
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:
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.
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.
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 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.
• 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.
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.
- Observe that as the admin panel is accessible, try to use this information in targeted attacks and brute force the username and password.
Impact
Low (depends on password policy, if password is cracked, then this is High)
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.
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
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
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.
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
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 Secure or HTTPOnly Cookie Flag
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
Fast-track your security testing
Start testing in 24 hours. Connect directly with our security experts. And centralize your testing using the Cobalt platform. Trust the pioneers of PtaaS to optimize your cybersecurity across your entire attack surface.
.svg){kind=icon}
.svg){kind=icon}
