CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By Carsten Eilers
WebSockets are intended to build bi-directional connections between a web browser and a server. This must be done in a safe way. In addition, the WebSockets have a huge disadvantage (to say it politely).
WebSockets, the Safe Way
For WebSocket connections you must follow the same rules as for all network connections: the communication partners must be authenticated if necessary, and if the transmission contains sensitive data, the connection must be encrypted.
In the case of Websockets, the client is authenticated by the server over the usual HTTP authentication mechanisms such as cookies, HTTP authentication or TLS authentication. For encryption you can use TLS (Transport Layer Security). While a conventional WebSocket connection is established via HTTP, a protected one uses HTTPS. The distinction is based on the URI schemes:
Normal connection: ws://{host}:{port}/{path to the server}
Secure connection: wss://{host}:{port}/{path to the server}
Regardless of the authentication and / or encryption of the data, the well-known principle “Never Trust the Client” also applies to the WebSockets: All received data must be checked by the server, the client may be under the control of an attacker. Additionally, the server can verify in the ‘Origin’ header if a connection request originates from a desired domain. As usual with client-delivered data, an attacker can spoof this header.
Now let’s take a look on the disadvantage of WebSockets:
WebSockets and the Same Origin Policy
Some descriptions of the WebSocket API indicate that the Same Origin Policy applies to WebSocket connections. But is this really so, and should it be at all? Apparently there is some confusion.
The WebSocket Protocol
In the standard for the WebSocket protocol, RFC 6455 [1], the abstract says: “The security model used for this is the origin-based security model commonly used by web browsers.” And the following is part of the introduction, which is not relevant for the standard (non-normative):
“1.6. Security Model
_This section is non-normative._
The WebSocket Protocol uses the origin model used by web browsers to restrict which web pages can contact a WebSocket server when the WebSocket Protocol is used from a web page. Naturally, when the WebSocket Protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the origin model is not useful, as the client can provide any arbitrary origin string.”
Additionally, there is a reference to RFC 6454 [2], in which the Same Origin Policy is specified.
In the actual definition of the protocol it is defined that the web browser must enclose an ‘Origin’ header while connecting, while this is optional for all other clients. In section 10, “Security Considerations“, it is accordingly also noted that the ‘Origin’ header can only protect against attacks from malicious JavaScript code in a web browser (because the header is then sent by the browser and not from the JavaScript code) and the server should assume that the ‘Origin’ header may be forged. Since independent WebSocket clients can send the header too, its existence is not even an indication that the connection request comes from a web browser.
Interim Conclusion 1
Although the web browser must send an ‘Origin’ header to the server, the Same Origin Policy is not applied. Otherwise the ‘Origin’ header would be obsolete, since the connection request would only be sent by the browser if it went to the Origin of the initiating JavaScript code.
The WebSocket API
Now let’s take a look at the definition of the WebSocket API [3]. In this there is no mention of the Same Origin Policy. If the Same Origin Policy applies, the API definition had to specify that WebSocket connections are only possible to the Origin of the JavaScript code, and an error message in case of a violation of the Same Origin Policy would be necessary. This leads to the conclusion that, by definition of the WebSocket API, the Same Origin Policy did not apply for WebSockets.
Interim Conclusion 2
The definition of WebSocket API does not require the Same Origin Policy. On the contrary, everything suggests that it is not applicable. Even if this is not explicitly stated anywhere.
The Practical Usage
Finally let’s take a look at the practical use of the WebSocket API. The Attack and Defense Labs developed a JavaScript-based port scanner, JS-Recon [4], [5]. It uses the WebSockets API to connect to any IP address on the local network, which would violate the Same Origin Policy if it would apply.
Conclusion
This all leads to one conclusion: The application of the Same Origin Policy is neither required by the protocol itself nor by the API. And in practice it is not observed.
About the Author
Carsten Eilers is a freelance consultant and coach on IT security and technical data protection. His work focuses on the security of web applications, local networks and individual client computers. He is not only a regular contributor to German publications PHP Magazin and Entwickler Magazin, but also writes for other magazines and online media. He can be contacted at http://www.ceilers-it.de, and has a blog containing articles on IT security fundamentals and commentaries relating to current developments at http://www.ceilers-news.de. Carsten is the author of HTML5 Security Developer.Press
Bibliography
1.RFC 6455 – The WebSocket Protocol: http://tools.ietf.org/html/rfc6455
2.RFC 6454 – The Web Origin Concept: http://tools.ietf.org/html/rfc6454
3.The WebSocket API: http://dev.w3.org/html5/websockets/
4.Attack and Defense Labs: „JS-Recon, HTML5 based JavaScript Network Reconnaissance Tool“, Description: http://www.andlabs.org/tools/jsrecon/jsrecon.html
5.JS-Recon – HTML5 based JavaScript Network Reconnaissance Tool: http://www.andlabs.org/tools/jsrecon.html
6.Qualys Security Labs: The Tiny Mighty Waldo: https://community.qualys.com/blogs/securitylabs/2012/08/03/the-tiny-mighty-waldo
This article was reprinted with permission from http://developerpress.com/ Developer.Press.
