Security Testing HTML5 WebSockets

Recently I became faced with my first Web Application Security Assessment which relied heavily on HTML5′s WebSockets.

The first clue that the application was using WebSockets was when the application kept giving me a timeout error while using my proxy of choice, Burp Suite. Looking at the HTTP requests/responses in Burp I noticed that a large JavaScript file was requested and downloaded from the server. Within this file I noticed a URL with the ws:// scheme, the WebSocket scheme.

TCP/HTTP?

The initial WebSocket handshake is carried out over HTTP using an ‘upgrade request‘. After the initial exchange over HTTP all future communication is carried out over TCP. On the application I was testing the WebSocket handshake over HTTP within WireShark looked like this:

Request:

GET /SocketHandler HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Sec-WebSocket-Version: 13
Origin: http://www.example.com
Sec-WebSocket-Key: iiral7et1zfQMGu9udIYHA==
Cookie: Login=1234567
Connection: keep-alive, Upgrade
Upgrade: websocket
Content-length: 0
Host: www.example.com

Response:

HTTP/1.1 101 Switching Protocols
Upgrade: Websocket
Server: Microsoft-IIS/8.0
Sec-WebSocket-Accept: 9ZPK0lC0SB6dhIJHRt3q/GN88Ng=
Connection: Upgrade
Date: Fri, 30 Aug 2013 13:33:42 GMT

Capturing WebSockets

For some reason the WebSocket handshake was not captured by Burp’s Proxy (even though the WireShark capture shows that the handshake was over HTTP), however, it can be viewed within Google Chrome’s Developer Tools and OWASP’s ZAP Proxy.

Using this example WebSocket application (which is vulnerable to ‘Self-XSS‘ BTW) you can see that Google Chrome’s Developer Tools captures the initial WebSocket handshake:

chrome developer tools web sockets

And also the subsequent WebSocket communication (frames) over TCP:

chrome developer tools web sockets 2

If you want to fuzz and replay WebSocket communications you can use OWASP’s ZAP Proxy which supports capturing and replaying WebSockets.

Encryption (SSL/TLS)

WebSockets can be used over unencrypted TCP or over encrypted TLS. To use unencrypted WebSockets the ws:// URI scheme is used (default port 80), to use encrypted (TLS) WebSockets the wss:// URI scheme is used (default port 443).

Here you probably want to look out for the OWASP Top 10 2013 A6-Sensitive Data Exposure type issues. Is sensitive data being transported over unencrypted channels? Has SSL been implemented securely?

Origin

It is the web server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the Origin header is not properly checked, the application may be vulnerable to OWASP Top 10 2013 A8-Cross-Site Request Forgery (CSRF).

There’s a great blog post here describing a ‘Cross-Site WebSocket Hijacking’ technique which is possible when the application/server does not check the Origin header.

I also created a WebSocket client which can be used to test origin issues which can be found here.

Authentication

WebSockets do not handle authentication, instead normal application authentication mechanisms apply, such as cookies, HTTP Authentication or TLS authentication. Here you probably want to check for OWASP Top 10 2013 A2-Broken Authentication and Session Management type issues.

Authorisation

WebSockets do not handle authorisation, normal application authorisation mechanisms apply. Here you want to test for OWASP Top 10 2013 A4-Insecure Direct Object References and OWASP Top 10 2013 A7-Missing Function Level Access Control.

Input Sanitisation

As with any data originating from untrusted sources the data should not be trusted. The OWASP Top 10 2013 A1-Injection and the OWASP Top 10 2013 A3-Cross-Site Scripting (XSS) issues would apply here.

There’s a great post here showing how an XSS issue on a page can be used to compromise WebSockets to eavesdrop on the WebSocket communications by modifying the JavaScript WebSocket functions.

Conclusion

Testing WebSockets can seem daunting when you first come across them during a Web Application Security Assessment. Hopefully you now have some insight of how WebSockets work, what tools you can use and what security issues to look out for.

I have probably not covered all bases here and I’m sure there is a lot more to be discussed surrounding testing WebSockets during a Web Application Security Assessment. If you think that I have missed anything out, please comment below!

Further Reading

https://tools.ietf.org/html/rfc6455
https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet
http://www.digininja.org/blog/zap_web_sockets.php
http://www.digininja.org/blog/zap_fuzzing.php

5 thoughts on “Security Testing HTML5 WebSockets

  1. Ken

    But is there way to implement websockets that’s just as secure or more secure than standard corporate security recommendations?

    Reply
  2. adrian

    can any one know .how can i send the websocket request into burp intruder . i want to fuzz a websocket

    Reply
  3. hay day hack ios no jailbreak

    This is the right web site for anybody who hopes to understand this topic.
    You know so much its almost hard to argue with you (not that I
    really will need to…HaHa). You definitely put a brand new spin on a topic that has been written about
    for ages. Excellent stuff, just excellent!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>