NoorQureshi WebSocket attacks
When it applies
The app uses WebSockets for realtime features. They're often less-tested than HTTP and skip the authz/validation the REST API has — plus the handshake can be CSRF-able.
Why it works
The WS handshake is an HTTP request that carries cookies; if the server authenticates by cookie
alone and doesn't check Origin, any site can open a socket as the victim (Cross-Site WebSocket
Hijacking). And per-message authorization is frequently missing — the server trusts the connection.
Method
- Intercept & replay: use Burp's WebSocket history to read/modify messages; tamper fields (ids, roles, amounts) and resend — test per-message authz (IDOR/BOLA over the socket).
- CSWSH: check if the handshake validates
Origin. If not and auth is cookie-based, host a page that opensnew WebSocket('wss://target/…')as the victim, then exfiltrate the messages the server sends back → data theft / actions. - Injection: message fields feed backends — test XSS (messages rendered to other users), SQLi/NoSQLi in socket payloads.
- Auth gaps: connect without/with a low-priv token; access channels/rooms you shouldn't.
Gotchas
- CSWSH impact = whatever the socket exposes (private messages, actions) — prove it reads/does something sensitive.
- Origin check present ≠ safe if it's a weak regex; test bypasses like
web-cors. - Stored-XSS via chat messages hits other connected users — high impact, easy to miss.
Verify success
Cross-origin socket reading victim data (CSWSH), a tampered message performing an unauthorized action, or an injection firing through a socket message.
References
PortSwigger WebSocket labs; OWASP testing WebSockets (WSTG).