Vulnerability Detection Modules

The following files were used as context for generating this wiki page:

• .github/workflows/ghcr-publish.yml
• README.md
• requirements.txt
• wshawk/main.py
• wshawk/advanced_cli.py
• wshawk/scanner_v2.py

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

flowchart TD
    WSHawkV2["WSHawkV2<br/>(scanner_v2.py)"]
    Learning["Learning Phase<br/>learning_phase()"]
    
    subgraph Intelligence["Intelligence Layer"]
        MessageIntel["MessageIntelligence<br/>detect format<br/>find injectable fields"]
        ServerFinger["ServerFingerprinter<br/>detect tech stack<br/>recommend payloads"]
        VulnVerifier["VulnerabilityVerifier<br/>analyze responses<br/>reduce false positives"]
    end
    
    subgraph PayloadSources["Payload Sources"]
        WSPayloads["WSPayloads<br/>(__main__.py)"]
        PayloadFiles["Payload Files<br/>(payloads/*.txt)"]
        Mutation["Mutation Engine<br/>(mutators/)"]
    end
    
    subgraph DetectionModules["Detection Modules"]
        SQLTest["test_sql_injection_v2()<br/>scanner_v2.py:143-213"]
        XSSTest["test_xss_v2()<br/>scanner_v2.py:215-293"]
        CmdTest["test_command_injection_v2()<br/>scanner_v2.py:295-359"]
        PathTest["test_path_traversal_v2()<br/>scanner_v2.py:361-400"]
        XXETest["test_xxe_v2()<br/>scanner_v2.py:402-456"]
        NoSQLTest["test_nosql_injection_v2()<br/>scanner_v2.py:458-496"]
        SSRFTest["test_ssrf_v2()<br/>scanner_v2.py:498-543"]
    end
    
    WSHawkV2 --> Learning
    Learning --> MessageIntel
    Learning --> ServerFinger
    
    WSPayloads --> SQLTest
    WSPayloads --> XSSTest
    WSPayloads --> CmdTest
    WSPayloads --> PathTest
    WSPayloads --> XXETest
    WSPayloads --> NoSQLTest
    
    PayloadFiles --> WSPayloads
    Mutation --> SQLTest
    Mutation --> XSSTest
    Mutation --> CmdTest
    
    ServerFinger --> SQLTest
    ServerFinger --> CmdTest
    MessageIntel --> SQLTest
    MessageIntel --> XSSTest
    MessageIntel --> CmdTest
    
    SQLTest --> VulnVerifier
    XSSTest --> VulnVerifier
    CmdTest --> VulnVerifier
    PathTest --> VulnVerifier
    XXETest --> VulnVerifier
    NoSQLTest --> VulnVerifier
    SSRFTest --> VulnVerifier

Sources: wshawk/scanner_v2.py:1-681, README.md:32-33

---

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:143-543, CHANGELOG.md:62-66

---

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:143-213

Workflow

flowchart LR
    Start["test_sql_injection_v2()"]
    GetPayloads["WSPayloads.get_sql_injection()<br/>[:100]"]
    Fingerprint["ServerFingerprinter<br/>.fingerprint()"]
    
    subgraph Conditional["Database Detected?"]
        DBSpecific["Get DB-specific payloads<br/>fingerprinter.get_recommended_payloads()"]
        Generic["Use generic payloads"]
    end
    
    Inject["MessageIntelligence<br/>.inject_payload_into_message()"]
    Send["ws.send(msg)"]
    Recv["ws.recv()"]
    Verify["VulnerabilityVerifier<br/>.verify_sql_injection()"]
    
    subgraph ConfidenceCheck["Confidence != LOW?"]
        LogVuln["Logger.vuln()<br/>Append to vulnerabilities[]"]
        Skip["Skip"]
    end
    
    Start --> GetPayloads
    Start --> Fingerprint
    GetPayloads --> Conditional
    Fingerprint --> Conditional
    Conditional --> Inject
    Inject --> Send
    Send --> Recv
    Recv --> Verify
    Verify --> ConfidenceCheck

Sources: wshawk/scanner_v2.py:143-213

Key Features

1. Database Fingerprinting Integration: Lines 153-158 check if ServerFingerprinter detected a specific database and retrieve database-specific payloads
2. Context-Aware Injection: Lines 166-169 use MessageIntelligence.inject_payload_into_message() to inject payloads into appropriate message fields
3. Confidence-Based Filtering: Lines 189-201 only report vulnerabilities with MEDIUM confidence or higher
4. 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:184-201

---

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:215-293

Dual Verification Architecture

flowchart TD
    Start["test_xss_v2()"]
    GetPayloads["WSPayloads.get_xss()<br/>[:100]"]
    Inject["MessageIntelligence<br/>.inject_payload_into_message()"]
    
    Send["ws.send(payload)"]
    Recv["ws.recv()"]
    
    VerifyPattern["VulnerabilityVerifier<br/>.verify_xss()<br/>Pattern + Context Analysis"]
    
    subgraph ConfidenceDecision["Confidence Level?"]
        Low["LOW: Skip"]
        MedHigh["MEDIUM/HIGH"]
        Critical["HIGH + Browser Enabled"]
    end
    
    Browser["HeadlessBrowserXSSVerifier<br/>.verify_xss_execution()<br/>Real JS Execution"]
    
    subgraph BrowserResult["Execution Verified?"]
        Executed["Update confidence to CRITICAL<br/>Add 'BROWSER VERIFIED' flag"]
        NotExecuted["Keep original confidence"]
    end
    
    Log["Logger.vuln()<br/>Append to vulnerabilities[]"]
    
    Start --> GetPayloads
    GetPayloads --> Inject
    Inject --> Send
    Send --> Recv
    Recv --> VerifyPattern
    VerifyPattern --> ConfidenceDecision
    
    MedHigh --> Log
    Critical --> Browser
    Browser --> BrowserResult
    BrowserResult --> Log

Sources: wshawk/scanner_v2.py:215-293

Browser Verification Enhancement

Lines 250-272 implement the optional Playwright verification:

1. Trigger Condition: Only activated for HIGH confidence findings when use_headless_browser = True
2. Lazy Initialization: HeadlessBrowserXSSVerifier is initialized only when needed (lines 253-255)
3. Confidence Escalation: Successfully verified payloads are upgraded to CRITICAL (line 263)
4. 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:250-272, README.md:24

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:244-246

---

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:295-359

OS-Aware Payload Selection

flowchart TD
    Start["test_command_injection_v2()"]
    GetPayloads["WSPayloads.get_command_injection()<br/>[:100]"]
    Fingerprint["ServerFingerprinter<br/>.fingerprint()<br/>Detect OS/Language"]
    
    subgraph PayloadDecision["Language Detected?"]
        OSSpecific["Get OS-specific command payloads<br/>fingerprinter.get_recommended_payloads()['command']"]
        Generic["Use generic command payloads"]
    end
    
    InjectLoop["For each payload"]
    Inject["MessageIntelligence<br/>.inject_payload_into_message()"]
    Send["ws.send(msg)"]
    Recv["ws.recv()"]
    Verify["VulnerabilityVerifier<br/>.verify_command_injection()"]
    
    subgraph VerificationChecks["Verification Checks"]
        OutputPattern["Command output patterns<br/>(uid, whoami, dir, etc.)"]
        ErrorPattern["Shell error patterns"]
        TimingAnomaly["Response time analysis"]
    end
    
    Start --> GetPayloads
    Start --> Fingerprint
    Fingerprint --> PayloadDecision
    GetPayloads --> PayloadDecision
    PayloadDecision --> InjectLoop
    InjectLoop --> Inject
    Inject --> Send
    Send --> Recv
    Recv --> Verify
    Verify --> VerificationChecks

Sources: wshawk/scanner_v2.py:295-359

Payload Adaptation Logic

Lines 305-310 demonstrate the fingerprint-based adaptation:

# Simplified from scanner_v2.py:305-310
fingerprint = self.fingerprinter.fingerprint()
if fingerprint.language:
    recommended = self.fingerprinter.get_recommended_payloads(fingerprint)
    if recommended.get('command'):
        Logger.info(f"Using {fingerprint.language}-specific command payloads")
        payloads = recommended['command'] + payloads[:50]

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:305-310

---

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:361-400

Detection Workflow

flowchart LR
    Start["test_path_traversal_v2()"]
    GetPayloads["WSPayloads.get_path_traversal()<br/>[:50]"]
    
    ForEach["For each payload"]
    BuildMsg["Build JSON message<br/>{action: 'read_file', filename: payload}"]
    Send["ws.send(msg)"]
    Recv["ws.recv()"]
    Verify["VulnerabilityVerifier<br/>.verify_path_traversal()"]
    
    subgraph Indicators["Detection Indicators"]
        FileContent["File content patterns<br/>(root:, [boot loader], etc.)"]
        ErrorMessage["Path error messages"]
        AccessSuccess["File access success indicators"]
    end
    
    Start --> GetPayloads
    GetPayloads --> ForEach
    ForEach --> BuildMsg
    BuildMsg --> Send
    Send --> Recv
    Recv --> Verify
    Verify --> Indicators

Sources: wshawk/scanner_v2.py:361-400

Hardcoded Message Structure

Unlike SQL/XSS/Command injection modules, path traversal uses a hardcoded message structure (line 370):

msg = json.dumps({"action": "read_file", "filename": payload})

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:370

---

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:402-456

OAST Integration Architecture

flowchart TD
    Start["test_xxe_v2()"]
    GetPayloads["WSPayloads.get_xxe()<br/>[:30]"]
    
    CheckOAST{"use_oast == True?"}
    StartOAST["OASTProvider<br/>.start()<br/>SimpleOASTServer on localhost:8888"]
    NoOAST["Use standard XXE payloads"]
    
    ForEach["For each payload"]
    
    subgraph PayloadGen["Payload Generation"]
        OASTPayload["oast_provider.generate_payload('xxe', 'test{N}')<br/>Injects OAST callback URL"]
        StandardPayload["Standard XXE payload"]
    end
    
    BuildMsg["Build JSON message<br/>{action: 'parse_xml', xml: payload}"]
    Send["ws.send(msg)"]
    Recv["ws.recv()"]
    
    subgraph Detection["Detection Methods"]
        InBand["In-band: Entity processing errors<br/>file:// disclosure"]
        OutOfBand["Out-of-band: OAST callbacks<br/>(DNS/HTTP to OAST server)"]
    end
    
    Start --> GetPayloads
    Start --> CheckOAST
    CheckOAST -->|Yes| StartOAST
    CheckOAST -->|No| NoOAST
    StartOAST --> ForEach
    NoOAST --> ForEach
    
    ForEach --> PayloadGen
    PayloadGen --> BuildMsg
    BuildMsg --> Send
    Send --> Recv
    Recv --> Detection

Sources: wshawk/scanner_v2.py:402-456

OAST Startup Logic

Lines 410-417 handle OAST provider initialization:

# Simplified from scanner_v2.py:410-417
if self.use_oast and not self.oast_provider:
    try:
        self.oast_provider = OASTProvider(use_interactsh=False, custom_server="localhost:8888")
        await self.oast_provider.start()
        Logger.info("OAST provider started for blind XXE detection")
    except Exception as e:
        Logger.error(f"OAST start failed: {e}")
        self.use_oast = False

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:410-417, README.md:25

Verification Patterns

Lines 435-436 define in-band detection indicators:

xxe_indicators = ['<!entity', 'system', 'file://', 'root:', 'XML Parse Error']

These patterns catch scenarios where the server reveals entity processing errors or file content.

Sources: wshawk/scanner_v2.py:435-447

---

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:458-496

Query Operator Injection

flowchart LR
    Start["test_nosql_injection_v2()"]
    GetPayloads["WSPayloads.get_nosql_injection()<br/>[:50]"]
    
    ForEach["For each payload"]
    BuildMsg["Build JSON message<br/>{action: 'find_user',<br/>query: {username: payload}}"]
    Send["ws.send(msg)"]
    Recv["ws.recv()"]
    
    subgraph Indicators["NoSQL Indicators"]
        DBName["Database name in error<br/>(mongodb, bson)"]
        Operators["Query operators revealed<br/>($ne, $gt, $where, etc.)"]
        Errors["Query error messages"]
    end
    
    CheckIndicators["Check for NoSQL indicators"]
    
    Start --> GetPayloads
    GetPayloads --> ForEach
    ForEach --> BuildMsg
    BuildMsg --> Send
    Send --> Recv
    Recv --> CheckIndicators
    CheckIndicators --> Indicators

Sources: wshawk/scanner_v2.py:458-496

Detection Indicators

Line 475 defines the NoSQL-specific patterns:

nosql_indicators = ['mongodb', 'bson', 'query error', '$ne', '$gt', 'Query Error']

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:467-487

---

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:498-543

Target Endpoint Strategy

flowchart TD
    Start["test_ssrf_v2()"]
    
    subgraph Targets["Internal Targets List"]
        Localhost["http://localhost<br/>http://127.0.0.1"]
        CloudMeta["http://169.254.169.254/latest/meta-data/<br/>AWS metadata endpoint"]
        GCPMeta["http://metadata.google.internal<br/>GCP metadata endpoint"]
    end
    
    ForEach["For each target"]
    RateLimit["TokenBucketRateLimiter<br/>.acquire()"]
    BuildMsg["Build JSON message<br/>{action: 'fetch_url', url: target}"]
    Send["ws.send(msg)"]
    Recv["ws.recv() with 3s timeout"]
    
    subgraph Indicators["SSRF Indicators"]
        ConnRefused["'connection refused'<br/>Internal endpoint exists"]
        Timeout["Timeout pattern<br/>Network request made"]
        Metadata["'metadata', 'instance-id'<br/>Cloud metadata accessed"]
        Localhost2["'localhost' in response"]
    end
    
    Start --> Targets
    Targets --> ForEach
    ForEach --> RateLimit
    RateLimit --> BuildMsg
    BuildMsg --> Send
    Send --> Recv
    Recv --> Indicators

Sources: wshawk/scanner_v2.py:498-543

Cloud Metadata Endpoints

Lines 503-508 define critical cloud metadata targets:

internal_targets = [
    'http://localhost',
    'http://127.0.0.1',
    'http://169.254.169.254/latest/meta-data/',  # AWS
    'http://metadata.google.internal',             # GCP
]

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:503-508

Rate Limiting Integration

Unlike other modules, SSRF testing explicitly uses the TokenBucketRateLimiter (line 512):

await self.rate_limiter.acquire()

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:512, wshawk/scanner_v2.py:45-49

---

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:

flowchart LR
    DetectedFormat["MessageIntelligence<br/>detected_format"]
    
    subgraph FormatTypes["Format Types"]
        JSON["MessageFormat.JSON"]
        XML["MessageFormat.XML"]
        Binary["MessageFormat.BINARY"]
        Text["MessageFormat.TEXT"]
    end
    
    InjectMethod["inject_payload_into_message()<br/>Injects into all injectable fields"]
    
    subgraph FieldTargets["Injectable Fields"]
        JSONFields["All string/number values"]
        XMLFields["Element text, attribute values"]
        TextFields["Full message replacement"]
    end
    
    InjectedMsgs["List of injected messages<br/>(one per field)"]
    
    DetectedFormat --> FormatTypes
    FormatTypes --> InjectMethod
    InjectMethod --> FieldTargets
    FieldTargets --> InjectedMsgs

Example from test_sql_injection_v2() (lines 166-169):

if self.learning_complete and self.message_intel.detected_format == MessageFormat.JSON:
    injected_messages = self.message_intel.inject_payload_into_message(
        base_message, payload
    )
else:
    injected_messages = [payload]

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:166-171, wshawk/scanner_v2.py:228-232, wshawk/scanner_v2.py:316-320

---

Verification Workflow Pattern

All modules follow a consistent verification pattern:

sequenceDiagram
    participant Module as "Detection Module"
    participant WS as "WebSocket"
    participant Verifier as "VulnerabilityVerifier"
    participant Logger as "Logger"
    participant VulnList as "vulnerabilities[]"
    
    Module->>WS: send(injected_payload)
    WS->>Module: recv(response)
    Module->>Verifier: verify_*_injection(response, payload)
    Verifier->>Verifier: Pattern matching<br/>Context analysis<br/>Timing analysis
    Verifier-->>Module: (is_vuln, confidence, description)
    
    alt confidence != LOW
        Module->>Logger: vuln(message)
        Module->>VulnList: append({type, severity, payload, ...})
    else confidence == LOW
        Module->>Module: Skip (false positive)
    end

This pattern is implemented in:

• SQL Injection: wshawk/scanner_v2.py:184-201
• XSS: wshawk/scanner_v2.py:244-283
• Command Injection: wshawk/scanner_v2.py:332-349
• Path Traversal: wshawk/scanner_v2.py:378-391

Sources: wshawk/scanner_v2.py:184-201, wshawk/scanner_v2.py:244-283

---

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):

self.vulnerabilities.append({
    'type': 'SQL Injection',
    'severity': confidence.value,
    'confidence': confidence.value,
    'description': description,
    'payload': payload,
    'response_snippet': response[:200],
    'recommendation': 'Use parameterized queries'
})

This standardized structure enables the EnhancedHTMLReporter to generate consistent reports across all vulnerability types.

Sources: wshawk/scanner_v2.py:193-201, wshawk/scanner_v2.py:273-282, wshawk/scanner_v2.py:340-348

---

Execution Flow in Main Scanner

The vulnerability detection modules are orchestrated by WSHawkV2.run_intelligent_scan():

flowchart TD
    Start["run_intelligent_scan()"]
    Connect["connect()<br/>Establish WebSocket"]
    Learning["learning_phase()<br/>5 seconds passive observation"]
    
    subgraph VulnTests["Vulnerability Detection Sequence"]
        SQL["test_sql_injection_v2()"]
        XSS["test_xss_v2()"]
        Cmd["test_command_injection_v2()"]
        Path["test_path_traversal_v2()"]
        XXE["test_xxe_v2()"]
        NoSQL["test_nosql_injection_v2()"]
        SSRF["test_ssrf_v2()"]
    end
    
    CloseWS["ws.close()"]
    Session["SessionHijackingTester<br/>.run_all_tests()"]
    
    subgraph Cleanup["Resource Cleanup"]
        BrowserStop["HeadlessBrowserXSSVerifier<br/>.stop()"]
        OASTStop["OASTProvider<br/>.stop()"]
    end
    
    Report["EnhancedHTMLReporter<br/>.generate_report()"]
    
    Start --> Connect
    Connect --> Learning
    Learning --> SQL
    SQL --> XSS
    XSS --> Cmd
    Cmd --> Path
    Path --> XXE
    XXE --> NoSQL
    NoSQL --> SSRF
    SSRF --> CloseWS
    CloseWS --> Session
    Session --> Cleanup
    Cleanup --> Report

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:545-680

---

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:150, wshawk/scanner_v2.py:222, wshawk/scanner_v2.py:302, wshawk/scanner_v2.py:365, wshawk/scanner_v2.py:407, wshawk/scanner_v2.py:463, wshawk/scanner_v2.py:503-508

---

Rate Limiting and Performance

All detection modules implement implicit rate limiting through asyncio.sleep() calls:

await asyncio.sleep(0.05)  # 50ms delay between payloads

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):

await self.rate_limiter.acquire()

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:207, wshawk/scanner_v2.py:288, wshawk/scanner_v2.py:354, wshawk/scanner_v2.py:512, wshawk/scanner_v2.py:45-49