| VID |
210149 |
| Severity |
40 |
| Port |
80, ... |
| Protocol |
TCP |
| Class |
CGI |
| Detailed Description |
WebSockets protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
Process the messages received by the websocket as data. Don't try to assign it directly to the DOM nor evaluate as code. If the response is JSON, never use the insecure eval() function; use the safe option JSON.parse() instead.
Endpoints exposed through the ws:// protocol are easily reversible to plain text. Only wss:// (WebSockets over SSL/TLS) should be used for protection against Man-In-The-Middle attacks.
Spoofing the client is possible outside a browser, so the WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
When implementing servers, check the Origin: header in the Websockets handshake. Though it might be spoofed outside a browser, browsers always add the Origin of the page that initiated the Websockets connection.
As a WebSockets client in a browser is accessible through JavaScript calls, all Websockets communication can be spoofed or hijacked through Cross Site Scripting. Always validate data coming through a WebSockets connection.
* References:
https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet
* Platforms Affected:
Any HTTP server Any version
Any operating system Any version |
| Recommendation |
Only 'wss://' (WebSockets over SSL/TLS) should be used instead of 'ws://'. Always validate input coming from the remote site, as it might have been altered. |
| Related URL |
(CVE) |
| Related URL |
(SecurityFocus) |
| Related URL |
(ISS) |
|
