WebSocket Hijacking Scanner
Detects cross-site WebSocket hijacking vulnerabilities.
What is WebSocket Hijacking?
Cross-Site WebSocket Hijacking (CSWSH) occurs when WebSocket connections don't validate the origin of the connecting page. Attackers host malicious pages that establish WebSocket connections to vulnerable servers, piggy-backing on the victim's authenticated session to perform unauthorized actions or steal data.
Why is This Important?
WebSocket connections often bypass CSRF protections because they don't use standard form submissions. If origin validation is missing, any website can connect to your WebSocket server with the victim's cookies. This enables real-time data theft, command injection, and persistent session hijacking.
How It Works
1. Attack Surface Mapping
Identifies complex attack vectors including race conditions, desync points, and logic flaws in your application.
2. Advanced Exploitation
Executes sophisticated attack techniques that bypass traditional security controls and detection mechanisms.
3. Impact Assessment
Demonstrates real-world impact with detailed exploitation chains and business risk analysis.
Key Capabilities
Expert-level security testing for sophisticated vulnerabilities that evade traditional scanning tools.
- Race condition and timing attack detection
- Request smuggling and desync analysis
- Business logic flaw identification
- Chained exploit development
- Protocol-level vulnerability testing
Frequently Asked Questions
How does WebSocket hijacking work?
Attacker hosts evil.com with JavaScript that creates new WebSocket('wss://vulnerable.com/socket'). When a logged-in victim visits evil.com, their browser sends cookies with the WebSocket upgrade request. If vulnerable.com doesn't check Origin, the attacker has an authenticated connection.
Why don't SameSite cookies prevent this?
WebSocket upgrade requests are not same-site, but whether cookies are sent depends on the SameSite attribute and browser behavior. SameSite=Strict blocks cookies, but many use Lax or None. Even without cookies, token-based auth in the WebSocket protocol may be vulnerable.
What can attackers do with hijacked WebSockets?
Attackers can: read all messages (real-time data theft), send messages as the victim (unauthorized actions), maintain persistent connection for ongoing access, combine with other attacks (send XSS payloads through WebSocket), and potentially escalate to account takeover.
How do I prevent WebSocket hijacking?
Prevention: validate Origin header against allowlist, use custom authentication tokens (not just cookies), implement CSRF tokens for WebSocket establishment, use unique connection tokens, and consider same-origin policy enforcement at the WebSocket level.
Related Scanners
Ready to secure your application?
Start testing for websocket hijacking vulnerabilities today.
Get Started Free