Uploaded image for project: 'Zeppelin'
  1. Zeppelin
  2. ZEPPELIN-173

Zeppelin websocket server is vulnerable to Cross-Site WebSocket Hijacking



    • Bug
    • Status: Resolved
    • Critical
    • Resolution: Fixed
    • 0.5.0
    • 0.5.5
    • Core
    • None


      The WebSocket specification - developed as part of the HTML5 initiative - introduced the WebSocket JavaScript interface, which defines a full-duplex single socket connection over which messages can be sent between client and server. In order to create a Websocket channel, the browser - via JavaScript - sends to the webserver a specific request, like the following:

      GET / HTTP/1.1
      Host: XXXXX:8004
      User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
      Accept-Language: en-US,en;q=0.5
      Accept-Encoding: gzip, deflate
      Sec-WebSocket-Version: 13
      Origin: XXXXXX:8003
      Sec-WebSocket-Extensions: permessage-deflate
      Sec-WebSocket-Key: jecleCYu+zulEtNfWPDUHQ==
      Authorization: Basic [...]
      Connection: keep-alive, Upgrade
      Pragma: no-cache
      Cache-Control: no-cache
      Upgrade: websocket

      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
      Upgrade: Websocket
      Server: Microsoft-IIS/8.5
      x-ms-hdi-servedby: GATEWAY0
      x-ms-hdi-active: headnode1.XXXX.net
      x-ms-leader-detect-time: 0
      X-Powered-By: ARR/2.5
      Sec-WebSocket-Accept: dsFIbttEBYGLWHitOKbGhmXyzeI=
      Connection: Upgrade
      X-Powered-By: ASP.NET
      X-Content-Type-Options: nosniff
      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.

      This means that an attacker could create a malicious website containing a malicious javascript code and force the victim user to open it (e.g., by sending an email). Once the client-side code is acquired and executed by the victim's browser, the attacker could control the websocket channel and, then, execute arbitrary code on the Spark cluster via Zeppelin.


      It is strongly recommended to apply a patch to the current Zeppelin version in order to check, at least, the Origin header.




            Unassigned Unassigned
            djoelz Joel Zambrano
            0 Vote for this issue
            8 Start watching this issue



              Time Tracking

                Original Estimate - 96h
                Remaining Estimate - 96h
                Time Spent - Not Specified
                Not Specified