CSWSH Test (Cross-Site WebSocket Hijacking)

Relevant source files

• docs/DEFENSIVE_VALIDATION.md
• wshawk/defensive_cli.py
• wshawk/defensive_validation.py
• wshawk/payloads/malicious_origins.txt
• wshawk/wss_security_validator.py

Purpose and Scope

This document describes the Cross-Site WebSocket Hijacking (CSWSH) validation test within WSHawk's defensive validation suite. The CSWSH test validates whether WebSocket servers properly implement Origin header validation and CSRF token requirements to prevent cross-site attacks. This module is designed for blue teams to assess the effectiveness of their CSWSH defenses.

For information about other defensive validation tests, see DNS Exfiltration Prevention Test, Bot Detection Validation Test, and WSS Protocol Security Validation. For offensive vulnerability testing, see Offensive Testing.

Sources: wshawk/defensive_validation.py L350-L475

docs/DEFENSIVE_VALIDATION.md L64-L85

---

Attack Scenario and Defensive Goal

Attack Scenario

Cross-Site WebSocket Hijacking exploits the lack of same-origin policy enforcement in WebSocket connections:

1. Attacker hosts a malicious webpage on https://evil-attacker.com
2. Victim with an active session visits the malicious page
3. Malicious JavaScript initiates a WebSocket connection to the victim's legitimate application
4. WebSocket connection inherits victim's session cookies
5. Attacker performs privileged actions using the victim's authenticated session

Defensive Goal

The CSWSH test validates three critical security controls:

| Security Control | Purpose | | --- | --- | | Origin Header Validation | Ensures WebSocket server only accepts connections from trusted origins | | CSRF Token Requirement | Validates that sensitive WebSocket messages require anti-CSRF tokens | | Cross-Site Connection Prevention | Prevents malicious sites from hijacking user sessions |

Sources: wshawk/defensive_validation.py L350-L366

docs/DEFENSIVE_VALIDATION.md L64-L77

---

Architecture and Components

Component Overview

Sources: wshawk/defensive_validation.py L350-L475

Class Hierarchy

The CSWSHValidator class inherits from DefensiveValidationModule, providing standardized finding management and reporting capabilities.

Sources: wshawk/defensive_validation.py L27-L46

wshawk/defensive_validation.py L350-L475

---

Test Modules

Origin Header Validation Test

The Origin header validation test attempts to establish WebSocket connections using 216+ malicious origins to identify whether the server properly validates the Origin header.

Test Implementation

The test is implemented in test_origin_validation() wshawk/defensive_validation.py L368-L428

:

Test Flow:

Sources: wshawk/defensive_validation.py L368-L428

Payload Loading Mechanism

The test loads malicious origins from the payload file with a fallback mechanism:

Sources: wshawk/defensive_validation.py L375-L391

Vulnerability Scoring

| Finding Status | Severity | CVSS Score | Description | | --- | --- | --- | --- | | Vulnerable | CRITICAL | 9.1 | Server accepts connections from untrusted origins | | Secure | INFO | 0.0 | Server properly validates Origin header |

Sources: wshawk/defensive_validation.py L409-L428

---

CSRF Token Requirement Test

The CSRF token test validates whether the WebSocket server requires anti-CSRF tokens for sensitive operations.

Test Implementation

The test is implemented in test_csrf_token_requirement() wshawk/defensive_validation.py L430-L461

:

Test Execution:

Sources: wshawk/defensive_validation.py L430-L461

Payload Structure

The test sends a simple payload to trigger a sensitive action:

If the server processes this request successfully without requiring a CSRF token, it indicates a vulnerability.

Sources: wshawk/defensive_validation.py L437-L440

Vulnerability Scoring

| Finding Status | Severity | CVSS Score | Description | | --- | --- | --- | --- | | Vulnerable | HIGH | 7.5 | WebSocket accepts sensitive actions without CSRF token | | Secure | N/A | 0.0 | No finding generated (test passes) |

Sources: wshawk/defensive_validation.py L446-L454

---

Test Execution Orchestration

Test Orchestration Method

The run_all_tests() method orchestrates both CSWSH validation tests:

Sources: wshawk/defensive_validation.py L463-L475

Integration with Defensive Validation Suite

The CSWSH validator is integrated into the main defensive validation suite via run_defensive_validation():

Sources: wshawk/defensive_validation.py L478-L557

wshawk/defensive_validation.py L514-L520

---

Malicious Origins Payload Collection

Payload File Structure

The malicious_origins.txt file contains 216+ malicious origin headers organized by attack category:

| Category | Example Origins | Count | | --- | --- | --- | | Generic Malicious | https://evil-attacker.com, https://malicious-site.net | ~20 | | Localhost Abuse | http://localhost:666, http://127.0.0.1:8080 | ~10 | | Internal Networks | http://192.168.1.1, http://10.0.0.1, http://172.16.0.1 | ~5 | | Phishing | https://fake-bank.com, https://paypal-secure-login.net | ~10 | | Attack Techniques | https://csrf-attack.com, https://session-hijack.io | ~15 | | Vulnerability Types | https://xxe-exploit.xml, https://ssrf-target.internal | ~20 | | DDoS/Network Attacks | https://dos-attack.net, http://ddos-botnet.cc | ~30 | | Amplification Attacks | http://dns-amplification.io, http://memcached-amplification.net | ~50 | | Supply Chain | https://npm-typosquat.net, https://pypi-malicious.org | ~20 | | Testing Tools | https://playwright-exploit.net, https://puppeteer-backdoor.io | ~20 | | CI/CD Platforms | https://gitlab-ci-malicious.io, http://github-actions-exploit.net | ~16 |

Sources: wshawk/payloads/malicious_origins.txt L1-L217

Payload Distribution

Sources: wshawk/payloads/malicious_origins.txt L1-L217

---

Finding Generation and Reporting

Finding Structure

Each finding generated by the CSWSH validator follows the standard DefensiveValidationModule finding structure:

Sources: wshawk/defensive_validation.py L35-L46

CVSS Scoring Matrix

| Test Name | Vulnerable Status | Severity | CVSS Score | Rationale | | --- | --- | --- | --- | --- | | Origin Header Validation | Vulnerable | CRITICAL | 9.1 | Allows complete session hijacking from any origin | | Origin Header Validation | Secure | INFO | 0.0 | Proper validation prevents CSWSH | | CSRF Token Requirement | Vulnerable | HIGH | 7.5 | Sensitive actions possible without CSRF protection | | CSRF Token Requirement | Secure | N/A | 0.0 | No finding generated |

Sources: wshawk/defensive_validation.py L409-L418

wshawk/defensive_validation.py L446-L454

docs/DEFENSIVE_VALIDATION.md L82-L84

Recommendation Templates

Origin Validation Failure

CRITICAL: Implement Origin header validation immediately. 
Only accept connections from trusted origins.

Sources: wshawk/defensive_validation.py L415-L416

CSRF Token Missing

Implement CSRF token validation for WebSocket messages.

Sources: wshawk/defensive_validation.py L451

---

Usage Examples

Command-Line Interface

Via wshawk-defensive Command

Sources: docs/DEFENSIVE_VALIDATION.md L142-L147

wshawk/defensive_cli.py L1-L56

Python API

Direct CSWSHValidator Usage

Sources: docs/DEFENSIVE_VALIDATION.md L182-L184

Individual Test Execution

Sources: wshawk/defensive_validation.py L368-L428

Integration with Full Defensive Suite

Sources: docs/DEFENSIVE_VALIDATION.md L151-L157

wshawk/defensive_validation.py L478-L557

---

Output Format

Console Output Example

[*] Testing CSWSH Prevention...

======================================================================
DEFENSIVE VALIDATION SUMMARY
======================================================================

Findings:
  CRITICAL: 1
  HIGH: 1
  MEDIUM: 0

[CRITICAL] CSWSH - Origin Header Validation
  Description: Server accepts WebSocket connections from untrusted origins: https://evil-attacker.com, http://localhost:666. CSWSH is possible.
  Recommendation: CRITICAL: Implement Origin header validation immediately. Only accept connections from trusted origins.
  CVSS: 9.1

[HIGH] CSRF Token Requirement
  Description: WebSocket accepts sensitive actions without CSRF token.
  Recommendation: Implement CSRF token validation for WebSocket messages.
  CVSS: 7.5

Sources: docs/DEFENSIVE_VALIDATION.md L220-L224

wshawk/defensive_validation.py L534-L556

Finding Data Structure

Each finding returned in the findings list contains:

Sources: docs/DEFENSIVE_VALIDATION.md L242-L252

wshawk/defensive_validation.py L35-L46

---

Remediation Guidance

Implementing Origin Header Validation

Python/websockets Example

Sources: docs/DEFENSIVE_VALIDATION.md L337-L352

Node.js/ws Example

Sources: docs/DEFENSIVE_VALIDATION.md L354-L372

Implementing CSRF Token Validation

Add token validation to WebSocket message handlers:

1. Generate unique token during WebSocket handshake
2. Require token in all sensitive message payloads
3. Validate token server-side before processing actions
4. Rotate tokens periodically for enhanced security

Sources: docs/DEFENSIVE_VALIDATION.md L328-L352

---

Integration Points

Entry Points

The CSWSH validator is accessible through multiple entry points:

| Entry Point | File | Purpose | | --- | --- | --- | | CLI Command | wshawk/defensive_cli.py | Direct command-line execution via wshawk-defensive | | Defensive Suite | wshawk/defensive_validation.py:478-557 | Integrated validation with DNS, Bot, and WSS tests | | Direct Import | wshawk/defensive_validation.py:350-475 | Programmatic access to CSWSHValidator class |

Sources: wshawk/defensive_cli.py L1-L56

wshawk/defensive_validation.py L478-L557

Dependencies

Sources: wshawk/defensive_validation.py L20-L25

wshawk/defensive_validation.py L350-L475

---

Limitations and Considerations

Test Limitations

| Limitation | Description | Impact | | --- | --- | --- | | Origin Header Only | Tests only Origin header validation, not full session security mechanisms | Does not validate session token security | | Single Payload Type | CSRF test uses generic sensitive_action payload | May not match actual application message format | | No Session Context | Tests do not establish authenticated sessions | Cannot verify session-specific protections | | Synchronous Testing | Tests origins sequentially, not in parallel | Slower execution with 216+ origins |

Sources: docs/DEFENSIVE_VALIDATION.md L428-L431

Best Practices

1. Get Authorization: Always obtain explicit written authorization before running tests
2. Test in Staging: Run validation against staging environments before production
3. Regular Testing: Schedule periodic validation to ensure defenses remain effective
4. Document Findings: Track all vulnerabilities and remediation status
5. Combine Tools: Use CSWSH test alongside other security tools for comprehensive coverage

Sources: docs/DEFENSIVE_VALIDATION.md L416-L423

wshawk/defensive_validation.py L1-L18

---

Error Handling

Exception Management

The CSWSH validator implements robust error handling:

Each test method catches exceptions and returns error dictionaries rather than propagating exceptions, ensuring the test suite continues even if individual tests fail.

Sources: wshawk/defensive_validation.py L405-L406

wshawk/defensive_validation.py L460-L461

---

Related Documentation

• For comprehensive defensive validation overview, see Defensive Validation
• For DNS exfiltration testing, see DNS Exfiltration Prevention Test
• For bot detection validation, see Bot Detection Validation Test
• For TLS/SSL security testing, see WSS Protocol Security Validation
• For CLI usage, see CLI Command Reference
• For Python API usage, see Python API Usage

Sources: docs/DEFENSIVE_VALIDATION.md L1-L463