Security Testing HTML5 WebSockets
Recently I became faced with my first Web Application Security Assessment which relied heavily on HTML5's WebSockets.
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:
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
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
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:
And also the subsequent WebSocket communication (frames) over TCP:
If you want to fuzz and replay WebSocket communications you can use OWASP's ZAP Proxy which supports capturing and replaying WebSockets.
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?
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.
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.
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.
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.
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!