Vulnerability Analytic Dashboard

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

Common vulnerabilities include:

• Violation of principle of least privilege or deny by default
• Bypassing access control checks by modifying the URL (parameter tampering or force browsing)
• Permitting viewing or editing someone else's account, by providing its unique identifier
• Accessing API with missing access controls for POST, PUT and DELETE
• Elevation of privilege: acting as a user without being logged in or acting as an admin when logged in as a user
• Metadata manipulation, such as replaying or tampering with JWT, cookies, or hidden fields
• CORS misconfiguration allowing API access from unauthorized/untrusted origins
• Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user

Cryptographic failures refer to weaknesses in the implementation of cryptography, which can lead to sensitive data exposure. Such failures can affect passwords, credit card numbers, health records, personal information, and business secrets.

Common issues include:

• Transmitting sensitive data in clear text
• Using deprecated cryptographic algorithms or protocols
• Using default or weak cryptographic keys
• Lack of proper key management
• Not enforcing encryption with security directives like HSTS
• Using weak password hashing algorithms
• Using initialization vectors incorrectly or reusing them
• Using cryptographic functions without setting the mode or with insecure modes

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Common injection types:

• SQL injection
• NoSQL injection
• OS command injection
• Object-Relational Mapping (ORM) injection
• LDAP injection
• Expression Language injection
• XML injection (including XXE)

Insecure design refers to a broad category of flaws expressed as "missing or ineffective control design." These issues cannot be fixed by perfect implementation as the flaws were introduced in the requirements or design phases.

Examples include:

• Lack of business risk profiling in the software development process
• Failing to determine the required security controls during design
• Creating unnecessarily complex user interfaces that may lead to security issues
• Lack of proper security requirements
• Inadequate threat modeling and secure design patterns
• Misuse of frameworks and libraries through insecure design patterns

Security misconfiguration is the most commonly seen issue, often resulting from insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.

Common examples include:

• Missing appropriate security hardening across application stack
• Improperly configured permissions on cloud services
• Unnecessary features enabled/installed (e.g., ports, services, pages, accounts, privileges)
• Default accounts and their passwords still enabled and unchanged
• Error handling revealing stack traces or overly informative error messages to users
• Latest security features disabled or not configured securely
• Missing security headers or directives, or not using them securely
• Outdated software with known vulnerabilities

Components, such as libraries, frameworks, and software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.

You are likely vulnerable if:

• You do not know the versions of all components you use
• Your software is vulnerable, unsupported, or out of date
• You don't scan for vulnerabilities regularly and subscribe to security bulletins
• You don't fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion
• Software developers do not test the compatibility of updated, upgraded, or patched libraries
• You do not secure the components' configurations

Authentication-related attacks can be used to assume other users' identities. Due to the prevalence of authentication in applications, attackers have various methods to compromise authentication.

Common authentication vulnerabilities include:

• Permitting automated attacks like credential stuffing
• Permitting brute force or other automated attacks
• Allowing weak or well-known passwords
• Using weak or ineffective credential recovery processes
• Using plain text, encrypted, or weakly hashed passwords for storage
• Missing or ineffective multi-factor authentication
• Exposing session IDs in the URL
• Not properly invalidating session IDs
• Not properly rotating session IDs after successful login
• Not properly securing session tokens

Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. Examples include where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and CDNs.

Common scenarios include:

• Use of untrusted CDNs, plugins, or libraries
• Inclusion of components from unverified sources
• Unsigned or unverified serialized data that is processed without verification
• Unsecured CI/CD pipelines that allow for unauthorized access or tampering
• Auto-updates without sufficient integrity verification
• Lack of proper digital signatures for critical data
• Deserialization of untrusted data

This category helps detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs at all stages of a breach.

Organizations should look for:

• Auditable events, such as logins, failed logins, and high-value transactions, not being logged
• Warnings and errors generating no, inadequate, or unclear log messages
• Logs of applications and APIs not being monitored for suspicious activity
• Logs being stored locally only
• Appropriate alerting thresholds and response escalation processes not in place
• SIEM systems or dashboards not in place for real-time analysis
• Penetration testing and scans by DAST tools not triggering alerts
• The application being unable to detect, escalate, or alert for active attacks in real-time or near real-time

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. This enables attackers to force the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or network ACL.

Prevention methods include:

• Network layer: Segment remote resource access functionality in separate networks
• Enforce "deny by default" firewall policies or network access control rules
• Application layer: Sanitize and validate all client-supplied input data
• Disable HTTP redirections
• Do not send raw responses to clients
• Use positive allowlisting with DNS resolution
• Never forward raw HTTP responses to clients