Advanced Web Attacks

5 automated security scanners

WebSocket Security

Purpose: The WebSocket Security Scanner is designed to identify and assess potential vulnerabilities in WebSocket connections, focusing on insecure endpoints, origin validation issues, lack of authentication mechanisms, transport layer security concerns, and message injection vulnerabilities. This tool aims to protect real-time communication channels from potential attacks such as Cross-Site WebSocket Hijacking (CSWSH), unauthorized data interception, and command injections via malformed messages.

What It Detects:

WebSocket Endpoint Detection: Identifies endpoints that support the WebSocket upgrade protocol and checks for common paths used by frameworks like Socket.IO.
Origin Validation Testing: Evaluates whether WebSocket connections respect the Origin header to prevent unauthorized origins from connecting.
Authentication Mechanism Analysis: Assesses if unauthenticated connections are allowed, which could lead to data interception.
Transport Security Validation: Verifies that secure WebSocket (wss://) is used instead of insecure plaintext WebSockets (ws://).
Message Injection Testing: Investigates the handling of malformed messages and potential command injection vectors within WebSocket communications.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that represents the target system to be scanned for WebSocket vulnerabilities.

Business Impact: The detection of insecure WebSocket configurations can significantly impact an organization’s security posture, as it allows attackers to bypass traditional network boundaries and gain unauthorized access to real-time data streams. This can lead to severe consequences such as data theft, manipulation, or disruption of critical services.

Risk Levels:

Critical: Vulnerabilities that directly enable unauthenticated connections or allow unrestricted message injection pose a high risk, potentially leading to the compromise of sensitive information in real time.
High: Insecure WebSocket endpoints and missing origin validation can lead to unauthorized access and data interception, affecting both confidentiality and integrity.
Medium: Issues related to transport security (using ws:// instead of wss://) may expose transmitted data to eavesdropping but do not directly compromise authentication or authorization mechanisms.
Low: Informational findings regarding the presence of common WebSocket paths might indicate a need for better endpoint management rather than an immediate threat.
Info: These are generally less critical as they primarily affect usability and configuration practices, though ongoing monitoring is advised to ensure compliance with security best practices.

Example Findings:

An identified WebSocket endpoint that defaults to insecure ws:// protocol without any indication of upgrade to wss://.
A detected Socket.IO framework path that does not enforce Origin header validation, allowing connections from potentially malicious origins.

This formatted documentation provides a clear and concise overview of the purpose, inputs, business impact, risk levels, and potential findings associated with the WebSocket Security Scanner, tailored for an end-user audience.

Server-Side Request Forgery

Purpose: The Server-Side Request Forgery Scanner is designed to identify and assess vulnerabilities related to Server-Side Request Forgery (SSRF) by examining URL parameter injection points, testing internal network access, checking for cloud metadata endpoint exposure, validating URL parsing weaknesses, and detecting blind SSRF vectors that enable the enumeration of internal services and theft of credentials.

What It Detects:

URL Parameter Detection: Identifies common SSRF-prone parameters such as url, uri, path, redirect, callback, which are used to test for vulnerabilities in URL handling.
Cloud Metadata Access Testing: Tests access to AWS IMDSv1/v2, GCP, and Azure metadata endpoints to detect unauthorized exposure of cloud service credentials and information.
Internal Network Probing: Checks for accessibility to localhost, private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), DNS rebinding vulnerabilities, and unrestricted outbound connections that could be used for internal reconnaissance or port scanning.
Protocol Handler Testing: Evaluates the support for file:// and other exotic protocols to detect potential SSRF vectors through URL parsing weaknesses.
URL Parser Bypass Testing: Analyzes inconsistencies in URL parsing to identify bypass techniques, including CRLF injection and open redirects that can lead to SSRF chains.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) which serves as the target for the scanner’s analysis.

Business Impact: SSRF vulnerabilities pose a significant threat to web applications, enabling attackers to access critical cloud services, conduct internal network reconnaissance, bypass security controls, and steal sensitive information such as credentials. This can lead to unauthorized data exposure, service disruption, and compromise of application integrity.

Risk Levels:

Critical: Vulnerabilities that allow direct access to AWS IMDSv1/v2, GCP, Azure metadata endpoints or significant risk in internal network probing (e.g., accessing private IP ranges).
High: Exposure of local file system access via the file:// protocol or other high-risk probes into internal networks.
Medium: Issues related to URL parameter handling and some forms of internal service enumeration that may be mitigated but still pose a risk if not addressed.
Low: Minor issues in URL parsing and protocol support which generally do not lead to significant risks unless combined with other vulnerabilities.
Info: Informal findings indicating potential SSRF vectors that require further investigation or are unlikely to cause substantial harm without additional exploitation.

Example Findings:

An application exposes a webhook endpoint accepting arbitrary URLs, potentially allowing an attacker to trigger internal service requests and extract sensitive data.
A cloud-based service is configured to allow metadata access via public endpoints, which could be exploited by malicious users to gather information about the infrastructure.

This documentation provides a clear overview of the purpose, detection capabilities, input requirements, business impact, risk levels, and potential findings associated with the Server-Side Request Forgery Scanner, ensuring that it is understood as a valuable tool for assessing SSRF risks in web applications.

GraphQL Security

Purpose: The GraphQL Security Scanner is designed to identify and assess potential vulnerabilities in GraphQL endpoints by examining several critical aspects such as introspection exposure, query depth limitations, field authorization checks, batching attack vulnerabilities, and mutation access controls. This tool aims to protect applications from security threats introduced through GraphQL interfaces.

What It Detects:

Introspection Query Exposure: The scanner detects if the GraphQL endpoint is accessible on a domain and retrieves its schema using an introspection query. It checks whether introspection is enabled, counts total types and fields exposed, and flags production endpoints with introspection enabled.
Query Depth Limit Testing: The scanner crafts deeply nested GraphQL queries to test the server’s ability to handle complex requests without overloading resources. This includes testing query depth limits up to 100 levels.
Query Cost Analysis: It sends complex queries with many fields to analyze resource usage and detect cost-based rate limiting or potential exhaustion vectors. Aliased field duplication attacks are also tested during this phase.
Batching Attack Vulnerability: The scanner explores the support for batch queries, checking if multiple operations can be sent in a single request. It identifies authentication bypass via batching and tests amplification of credential stuffing attacks.
Mutation Access Control: The tool enumerates available mutations, checks their accessibility without proper authentication, verifies authorization on sensitive operations, and flags publicly accessible write operations.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that represents the target GraphQL endpoint.

Business Impact: This scanner is crucial for maintaining secure API interfaces, as misconfigurations in these endpoints can lead to unauthorized data exposure and service disruptions. Properly configured GraphQL servers are essential for safeguarding sensitive information and ensuring a reliable user experience.

Risk Levels:

Critical: Introspection enabled on production endpoints exposing complete schema details; absence of depth limiting allowing resource exhaustion DoS attacks; publicly accessible write operations without proper authorization.
High: Missing field authorization that results in exposure of sensitive data; query complexity limits not enforced, leading to potential denial of service via complex queries.
Medium: Query batching enabled with no size restrictions or authentication checks, which can be exploited for credential stuffing and other attacks.
Low: Minimal impact findings such as unauthenticated access to mutations that do not affect critical data or operations.
Info: Findings related to query depth testing where the limit is already set sufficiently high to avoid DoS risks but are still informative about endpoint configuration.

If specific risk levels are not defined in the README, they have been inferred based on typical impacts of each detection point.

Example Findings:

An application exposes its entire GraphQL schema through an unauthenticated introspection query, allowing attackers to craft targeted attacks.
A server does not enforce a depth limit for queries, making it susceptible to complex DoS attacks via deeply nested requests.
Public mutations that allow users to delete or update sensitive data are accessible without authentication, posing significant risks.

This documentation provides a clear and detailed overview of the GraphQL Security Scanner’s purpose, functionalities, inputs required, business impact, risk levels, and potential findings, suitable for both technical and non-technical stakeholders.

DOM-Based Vulnerabilities

Purpose: The DOM-Based Vulnerabilities Scanner is designed to identify and assess client-side vulnerabilities related to the Document Object Model (DOM) in web applications. This includes detecting potential cross-site scripting (XSS) attacks where user input is directly integrated into JavaScript execution contexts, often bypassing traditional server-side security measures.

What It Detects:

JavaScript Sink Detection: The scanner fetches HTML content from the target domain and analyzes JavaScript code to identify unsafe usage of sinks such as eval(), innerHTML, and document.write(). It also flags paths where user input might be unvalidated, potentially leading to DOM XSS vulnerabilities.
URL Fragment Analysis: The scanner tests the domain with malicious URL fragments that could reflect back into the DOM, checking for proper sanitization of location.hash and detecting potential reflected XSS via URL parameters or window.name.
Client-Side Template Usage: It identifies common client-side templating frameworks like Angular, Vue, and React, evaluating their template engines for unsafe variable interpolation that could lead to expression injection vulnerabilities.
PostMessage Handler Security: The scanner tests for the presence of postMessage event listeners, verifying if they correctly handle origin validation when handling messages that might flow into dangerous sinks.
Storage-Based DOM XSS: It checks for usage of localStorage and sessionStorage, evaluating whether stored data is sanitized before being integrated into innerHTML or other DOM manipulation functions.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com), which serves as the target for the scan to analyze potential vulnerabilities in its JavaScript and HTML interactions.

Business Impact: This scanner is crucial for maintaining the security of web applications by proactively identifying client-side vulnerabilities that could be exploited to steal sensitive information, hijack user sessions, or execute arbitrary code. These types of attacks can have significant business impacts, including financial loss, reputational damage, and compliance fines.

Risk Levels:

Critical: Vulnerabilities are critical if they enable direct theft of credentials, session hijacking, or the execution of arbitrary code without user interaction.
High: High severity is assigned to vulnerabilities that allow for significant data exposure or manipulation within the application context.
Medium: Medium risk levels apply where there is a potential for sensitive information leakage or limited impact on application functionality.
Low: Low risk findings are typically informational, indicating areas of improvement but not posing immediate threats.

Example Findings:

A detected eval() usage in JavaScript code potentially allows for DOM XSS if user input is processed without proper sanitization.
An improperly sanitized location.hash can lead to a reflected XSS attack when the hash value is included in page content.

This documentation provides a clear, comprehensive overview of the purpose and capabilities of the DOM-Based Vulnerabilities Scanner, detailing what it detects, the inputs required for operation, its business impact, risk levels associated with findings, and illustrative examples of potential vulnerabilities it might uncover.

Web Cache Poisoning

Purpose: The Web Cache Poisoning Scanner is designed to identify web cache poisoning vulnerabilities by detecting unkeyed input parameters, testing cache key manipulation, validating HTTP header reflection, checking for Host header injection, and analyzing cache behavior that enables serving malicious content to multiple users through poisoned cache entries.

What It Detects:

Identify HTTP headers not included in cache key
Test X-Forwarded-Host header reflection
Check X-Original-URL header processing
Detect unkeyed query parameters
Flag headers reflected in responses
Test Host header manipulation
Check for Host header reflection in URLs
Verify absolute URL generation
Test password reset link poisoning
Detect open redirect via Host header
Test parameter pollution attacks
Check cache key case sensitivity
Test URL encoding variations
Verify parameter order handling
Detect cache key collision vulnerabilities
Test X-Forwarded-For reflection
Check User-Agent header injection
Test custom header reflection
Verify Content-Type header handling
Detect reflected headers in cache
Detect caching proxy presence
Check cache control headers
Test Vary header implementation
Verify cache purge mechanisms
Identify cache poisoning attack surface

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com)

Business Impact: Cache poisoning vulnerabilities enable a wide range of malicious activities, including serving harmful JavaScript to multiple users, bypassing Web Application Firewalls with poisoned payloads, and executing stored cross-site scripting (XSS) attacks through the cache mechanism. This can lead to significant security breaches and unauthorized access to sensitive information.

Risk Levels:

Critical: Serve malicious JavaScript to all cached users; Poison CDN/proxy caches affecting thousands; Bypass Web Application Firewalls via cached payloads; Execute stored XSS through cache mechanism; Redirect users to phishing sites via poisoned redirects.
High: Cache poisoning can lead to widespread attacks, significantly impacting the security and integrity of web applications and their users.
Medium: While not as severe as critical, medium risk findings indicate potential vulnerabilities that should be addressed to enhance overall security.
Low: Informational findings suggest areas for improvement in cache handling mechanisms without immediate security risks.
Info: These are generally non-critical observations about the system’s configuration or behavior but can still provide valuable insights for better security practices.

Example Findings:

A web application reflects unkeyed query parameters in its responses, which could be exploited to inject malicious content into cached pages.
The Host header is not properly sanitized and allows injection of domains that redirect users to phishing sites.

This documentation provides a clear overview of the Web Cache Poisoning Scanner’s purpose, what it detects, required inputs, business impact, risk levels, and example findings based on typical vulnerabilities identified by such scanners.