Skip to main content

WebSockets meets Security

Posted by Developer.Press on June 11, 2013 at 7:28 AM PDT

WebSockets are intended to build bi-directional connections between a webbrowser 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 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. Additional 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 indicates 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.”

Additional 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 web browser must enclose a ‘Origin’ header while connecting, while this is optional for all other clients. In section 10, “Security Considerations“, 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 a ‘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 WebSockets 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. Which 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 appliable. Even if this is not explicitly stated anywhere.

The practical usage

Finally let’s take a look on 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.
“WebSockets Considered harmful!”

As a result, JavaScript code can establish WebSocket connections to any servers. It is up to the server to respond appropriately to unwanted connection requests, if necessary.
This applies even if the JavaScript code in question is a malicious one and has been injected, for example, via a XSS vulnerability. In this case, the code could then connect to the attacker’s server (which would accept the connection request, of course) and give the attacker access to the victim’s browser. How this could work shows for example “Waldo” [6], a proof-of-concept of the Qualys Security Labs, which implements a backdoor.

So WebSockets effectively subvert the Same Origin Policy. Although JavaScript code can not access the content of other Origins, JavaScript code injected in a web page can connect to any (WebSocket) server. I’m pretty sure this is not what the inventors had in mind. At least not the inventors of the Same Origin Policy.

To make it worse there is no mitigation or protection against such a misuse, since the old Atari excuse applies here: “It’s not a bug, it’s a feature”. As proetection, you can only completely disable WebSockets in your web browser, if you do not need it (and can find instructions how to do it for your browser).

Bibliography

RFC 6455 – The WebSocket Protocol: http://tools.ietf.org/html/rfc6455
RFC 6454 – The Web Origin Concept: http://tools.ietf.org/html/rfc6454
The WebSocket API: http://dev.w3.org/html5/websockets/
Attack and Defense Labs: „JS-Recon, HTML5 based JavaScript Network Reconnaissance Tool“, Description: http://www.andlabs.org/tools/jsrecon/jsrecon.html
JS-Recon – HTML5 based JavaScript Network Reconnaissance Tool: http://www.andlabs.org/tools/jsrecon.html
Qualys Security Labs: The Tiny Mighty Waldo: https://community.qualys.com/blogs/securitylabs/2012/08/03/the-tiny-migh...

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 athttp://www.ceilers-news.de.

Carsten has an ebook available now from Developer.Press on 'HTML5 Security'.
You can purchase it from the website: http://developerpress.com/en/html5 for only $3.99

Related Topics >>