GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept-Encoding: gzip, deflate
Authorization: Basic [...]
Connection: keep-alive, Upgrade
If the server accepts the request of upgrading the connection to a websocket channel, it will send back a http response with status code 101, like the following:
HTTP/1.1 101 Switching Protocols
Date: Tue, 09 Jun 2015 19:43:59 GMT
Because Websockets are not restrained by the same-origin policy, an attacker can easily initiate a Websocket request from a malicious webpage targeting the ws:// or wss:// endpoint URL of the attacked application. According to the RFC 6455, the Websocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication or TLS authentication. Because of that, the browser sends the authentication information along with the Websocket handshake/upgrade request, similar to a Cross-Site Request Forgery (CSRF), but in the Websocket scenario this attack can be extended from a write-only CSRF attack to a full read/write communication with a Websocket service.
One way to secure the Websocket server is to check the Origin http request header, which is automatically included by the browser and cannot be controlled by client-side code. According to our analysis, Zeppelin does not perform any check on the Origin header, allowing arbitrary Cross-Origin requests.
It is strongly recommended to apply a patch to the current Zeppelin version in order to check, at least, the Origin header.