Missing Origin Validation in WebSockets
Missing Origin Validation in WebSockets
CWE-1385
CVSS severity (NVD, All Time)
Per technology (GHSA, All time)
- 100%-NPM
Short description
Extended description
WebSockets provide a bi-directional low latency communication (near real-time) between a client and a server. WebSockets are different than HTTP in that the connections are long-lived, as the channel will remain open until the client or the server is ready to send the message, whereas in HTTP, once the response occurs (which typically happens immediately), the transaction completes.
A WebSocket can leverage the existing HTTP protocol over ports 80 and 443, but it is not limited to HTTP. WebSockets can make cross-origin requests that are not restricted by browser-based protection mechanisms such as the Same Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS). Without explicit origin validation, this makes CSRF attacks more powerful.
Best practices to prevent this CWE
Phase: Implementation
Enable CORS-like access restrictions by verifying the 'Origin' header during the WebSocket handshake.
Phase: Implementation
Use a randomized CSRF token to verify requests.
Phase: Implementation
Use TLS to securely communicate using 'wss' (WebSocket Secure) instead of 'ws'.
Phase: Architecture and Design; Implementation
Require user authentication prior to the WebSocket connection being established. For example, the WS library in Node has a 'verifyClient' function.
Phase: Implementation
Leverage rate limiting to prevent against DoS. Use of the leaky bucket algorithm can help with this.
Effectiveness: Defense in Depth
Phase: Implementation
Use a library that provides restriction of the payload size. For example, WS library for Node includes 'maxPayloadoption' that can be set.
Effectiveness: Defense in Depth
Phase: Implementation
Treat data/input as untrusted in both directions and apply the same data/input sanitization as XSS, SQLi, etc.
