Vulnerability Detection Modules
Vulnerability Detection Modules
Relevant source files
Purpose and Scope
This page documents the seven core vulnerability detection modules in WSHawk's offensive testing suite: SQL Injection, Cross-Site Scripting (XSS), Command Injection, Path Traversal, XML External Entity (XXE), NoSQL Injection, and Server-Side Request Forgery (SSRF). Each module implements context-aware payload injection, intelligent verification, and integration with WSHawk's intelligence layer.
For information about advanced verification techniques using Playwright and OAST, see Advanced Verification: Playwright and OAST. For session-level security testing, see Session Hijacking Tests. For details on the intelligence modules that support vulnerability detection, see Intelligence Modules.
Architecture Overview
All vulnerability detection modules follow a consistent three-phase architecture: Learning, Injection, and Verification. This architecture enables context-aware testing that adapts to the target application's message format and server technology.
Vulnerability Detection Pipeline
Sources: wshawk/scanner_v2.py L1-L681
Module Comparison Matrix
The following table summarizes the capabilities and characteristics of each vulnerability detection module:
| Module | Payloads Source | Intelligence Used | OAST Support | Verification Method | CVSS Range |
| --- | --- | --- | --- | --- | --- |
| SQL Injection | WSPayloads.get_sql_injection() | ServerFingerprinter (DB-specific), MessageIntelligence | No | Error patterns, timing attacks | 7.5-9.8 |
| XSS | WSPayloads.get_xss() | MessageIntelligence (context analysis) | No | Pattern matching, Playwright browser | 6.1-9.6 |
| Command Injection | WSPayloads.get_command_injection() | ServerFingerprinter (OS-specific), MessageIntelligence | No | Output patterns, timing attacks | 8.8-10.0 |
| Path Traversal | WSPayloads.get_path_traversal() | None | No | File content patterns | 6.5-7.5 |
| XXE | WSPayloads.get_xxe() | None | Yes | Entity processing errors, OAST callbacks | 7.5-9.1 |
| NoSQL Injection | WSPayloads.get_nosql_injection() | None | No | Query error patterns | 7.5-9.8 |
| SSRF | Hardcoded targets | None | Yes (future) | Internal endpoint responses | 8.6-9.1 |
Sources: wshawk/scanner_v2.py L143-L543
SQL Injection Detection
Implementation: test_sql_injection_v2()
The SQL injection module implements database fingerprint-aware testing with intelligent payload selection. It uses the ServerFingerprinter to detect the backend database technology and prioritizes database-specific payloads.
Location: wshawk/scanner_v2.py L143-L213
Workflow
Sources: wshawk/scanner_v2.py L143-L213
Key Features
- Database Fingerprinting Integration: Lines 153-158 check if
ServerFingerprinterdetected a specific database and retrieve database-specific payloads - Context-Aware Injection: Lines 166-169 use
MessageIntelligence.inject_payload_into_message()to inject payloads into appropriate message fields - Confidence-Based Filtering: Lines 189-201 only report vulnerabilities with
MEDIUMconfidence or higher - Adaptive Payload Set: Combines database-specific payloads with generic payloads (line 158)
Verification Logic
The VulnerabilityVerifier.verify_sql_injection() method analyzes responses for:
- Database error messages (MySQL, PostgreSQL, SQL Server, Oracle, SQLite)
- SQL syntax patterns
- Query execution indicators
- Timing anomalies (for blind SQL injection)
Sources: wshawk/scanner_v2.py L184-L201
Cross-Site Scripting (XSS) Detection
Implementation: test_xss_v2()
The XSS module is the most sophisticated detection module, featuring dual-layer verification: pattern-based detection followed by optional browser-based execution confirmation using Playwright.
Location: wshawk/scanner_v2.py L215-L293
Dual Verification Architecture
Sources: wshawk/scanner_v2.py L215-L293
Browser Verification Enhancement
Lines 250-272 implement the optional Playwright verification:
- Trigger Condition: Only activated for
HIGHconfidence findings whenuse_headless_browser = True - Lazy Initialization:
HeadlessBrowserXSSVerifieris initialized only when needed (lines 253-255) - Confidence Escalation: Successfully verified payloads are upgraded to
CRITICAL(line 263) - Evidence Capture: Browser verification provides detailed execution evidence (line 264)
This two-stage approach reduces false positives while minimizing resource overhead—browser automation only runs for high-confidence candidates.
Sources: wshawk/scanner_v2.py L250-L272
Context Analysis
The VulnerabilityVerifier.verify_xss() method performs context-aware analysis:
- HTML tag context detection
- JavaScript string context detection
- Attribute context detection
- Encoded vs. unencoded payload comparison
- Event handler execution patterns
Sources: wshawk/scanner_v2.py L244-L246
Command Injection Detection
Implementation: test_command_injection_v2()
The command injection module leverages operating system fingerprinting to deliver OS-specific payloads, improving detection accuracy and reducing false positives.
Location: wshawk/scanner_v2.py L295-L359
OS-Aware Payload Selection
Sources: wshawk/scanner_v2.py L295-L359
Payload Adaptation Logic
Lines 305-310 demonstrate the fingerprint-based adaptation:
This ensures Windows-specific payloads (e.g., & dir &, | type C:\Windows\win.ini) are tested against Windows servers, while Unix payloads (e.g., ; cat /etc/passwd, | whoami) target Unix-based systems.
Sources: wshawk/scanner_v2.py L305-L310
Path Traversal Detection
Implementation: test_path_traversal_v2()
The path traversal module tests file access vulnerabilities by injecting directory traversal sequences and analyzing responses for file content patterns.
Location: wshawk/scanner_v2.py L361-L400
Detection Workflow
Sources: wshawk/scanner_v2.py L361-L400
Hardcoded Message Structure
Unlike SQL/XSS/Command injection modules, path traversal uses a hardcoded message structure (line 370):
This assumes the target application has a file-reading action. In production scenarios, this would be adapted based on the MessageIntelligence analysis of observed message patterns.
Sources: wshawk/scanner_v2.py L370
XML External Entity (XXE) Detection
Implementation: test_xxe_v2()
The XXE module is unique in its integration with the OAST (Out-of-Band Application Security Testing) provider for detecting blind XXE vulnerabilities that don't produce visible errors.
Location: wshawk/scanner_v2.py L402-L456
OAST Integration Architecture
Sources: wshawk/scanner_v2.py L402-L456
OAST Startup Logic
Lines 410-417 handle OAST provider initialization:
The OAST server listens for DNS/HTTP callbacks, enabling detection of blind XXE vulnerabilities where the XML parser makes external requests without returning visible errors.
Sources: wshawk/scanner_v2.py L410-L417
Verification Patterns
Lines 435-436 define in-band detection indicators:
These patterns catch scenarios where the server reveals entity processing errors or file content.
Sources: wshawk/scanner_v2.py L435-L447
NoSQL Injection Detection
Implementation: test_nosql_injection_v2()
The NoSQL injection module targets MongoDB and other NoSQL databases by injecting query operators and analyzing error messages.
Location: wshawk/scanner_v2.py L458-L496
Query Operator Injection
Sources: wshawk/scanner_v2.py L458-L496
Detection Indicators
Line 475 defines the NoSQL-specific patterns:
These patterns identify:
- Database technology leakage:
mongodb,bson - Operator exposure:
$ne(not equal),$gt(greater than) - Error messages: Generic query errors
The module assumes a find_user action exists (line 467), similar to the path traversal assumption. Production deployments would adapt this based on application-specific message formats.
Sources: wshawk/scanner_v2.py L467-L487
Server-Side Request Forgery (SSRF) Detection
Implementation: test_ssrf_v2()
The SSRF module tests if the application can be coerced into making requests to internal or cloud metadata endpoints, which is critical for cloud environment security.
Location: wshawk/scanner_v2.py L498-L543
Target Endpoint Strategy
Sources: wshawk/scanner_v2.py L498-L543
Cloud Metadata Endpoints
Lines 503-508 define critical cloud metadata targets:
These endpoints are commonly used in SSRF attacks to:
- Access AWS EC2 instance metadata (credentials, IAM roles)
- Retrieve GCP instance metadata (service accounts, API tokens)
- Probe internal network services
Sources: wshawk/scanner_v2.py L503-L508
Rate Limiting Integration
Unlike other modules, SSRF testing explicitly uses the TokenBucketRateLimiter (line 512):
This prevents overwhelming the target server with rapid-fire internal network probes, which could trigger defensive mechanisms or cause service disruption.
Sources: wshawk/scanner_v2.py L512
Common Integration Patterns
Message Intelligence Integration
All detection modules (except Path Traversal, NoSQL, and SSRF) use MessageIntelligence.inject_payload_into_message() to adapt payloads to the detected message format:
Example from test_sql_injection_v2() (lines 166-169):
This allows the scanner to inject SQL payloads into every field of a JSON message structure discovered during the learning phase.
Sources: wshawk/scanner_v2.py L166-L171
wshawk/scanner_v2.py L228-L232
wshawk/scanner_v2.py L316-L320
Verification Workflow Pattern
All modules follow a consistent verification pattern:
This pattern is implemented in:
- SQL Injection: wshawk/scanner_v2.py L184-L201
- XSS: wshawk/scanner_v2.py L244-L283
- Command Injection: wshawk/scanner_v2.py L332-L349
- Path Traversal: wshawk/scanner_v2.py L378-L391
Sources: wshawk/scanner_v2.py L184-L201
wshawk/scanner_v2.py L244-L283
Vulnerability Record Structure
All modules append vulnerabilities to self.vulnerabilities[] with a consistent structure:
| Field | Type | Purpose |
| --- | --- | --- |
| type | string | Vulnerability category (e.g., "SQL Injection") |
| severity | string | CVSS severity level (CRITICAL/HIGH/MEDIUM/LOW) |
| confidence | string | Detection confidence (CRITICAL/HIGH/MEDIUM/LOW) |
| description | string | Human-readable description of the finding |
| payload | string | The payload that triggered the vulnerability |
| response_snippet | string | First 200 chars of the server response |
| recommendation | string | Remediation guidance |
| browser_verified | bool | (XSS only) Whether Playwright confirmed execution |
| cvss_score | float | (Session tests) Numeric CVSS score |
Example from SQL Injection (lines 193-201):
This standardized structure enables the EnhancedHTMLReporter to generate consistent reports across all vulnerability types.
Sources: wshawk/scanner_v2.py L193-L201
wshawk/scanner_v2.py L273-L282
wshawk/scanner_v2.py L340-L348
Execution Flow in Main Scanner
The vulnerability detection modules are orchestrated by WSHawkV2.run_intelligent_scan():
Execution details:
- Tests run sequentially (lines 568-587)
- Each test prints a separator line between tests (multiple
print()calls) - Session hijacking tests run after closing the main WebSocket (lines 593-616)
- Resource cleanup happens before report generation (lines 618-631)
Sources: wshawk/scanner_v2.py L545-L680
Payload Counts and Performance
The following table shows the default payload limits used by each module:
| Module | Method | Default Limit | Full Payload Count | Rationale |
| --- | --- | --- | --- | --- |
| SQL Injection | get_sql_injection()[:100] | 100 | 22,000+ | Balance coverage and speed |
| XSS | get_xss()[:100] | 100 | 22,000+ | Browser verification is expensive |
| Command Injection | get_command_injection()[:100] | 100 | 22,000+ | OS-specific payloads reduce set |
| Path Traversal | get_path_traversal()[:50] | 50 | 1,000+ | Limited patterns needed |
| XXE | get_xxe()[:30] | 30 | 500+ | OAST verification adds time |
| NoSQL Injection | get_nosql_injection()[:50] | 50 | 1,000+ | Database-specific operators |
| SSRF | Hardcoded list | 4 | N/A | Targeted endpoint probing |
These limits can be removed by modifying the slice operations (e.g., changing [:100] to [:] to use all payloads).
Sources: wshawk/scanner_v2.py L150
wshawk/scanner_v2.py L503-L508
Rate Limiting and Performance
All detection modules implement implicit rate limiting through asyncio.sleep() calls:
This creates an approximate rate limit of 20 requests/second, though the actual rate is lower due to network latency and processing time.
The SSRF module additionally uses explicit token bucket rate limiting (line 512):
The TokenBucketRateLimiter is initialized with max_rps=10 by default (lines 45-49), providing adaptive rate limiting that responds to server performance.
Sources: wshawk/scanner_v2.py L207