Maybe the most radical addition in HTML5 is the introduction of WebSockets as a persistent bidirectional communication between the client and server over the HTTP protocol, which is a stateless protocol.

As mentioned in Chapter 1, Introduction to Penetration Testing and Web Applications, WebSockets communication starts with the handshake between client and server. In the code shown in the following screenshot, taken from Damn Vulnerable Web Sockets (https://github.com/snoopysecurity/dvws), you can see a basic JavaScript implementation of WebSockets:

This code starts a WebSockets connection as soon as the HTML document is loaded. It then sets the event handlers for when the connection is established, when a message arrives, and when the connection closes or an error occurs. When the page loads the request to initiate the connection, it looks like this:

When the connection is accepted, the server will respond as follows:

Notice that Sec-WebSocket-Key in the request and Sec-WebSocket-Accept in the response are used only for the sake of the handshake and starting the connection. They are not an authentication or authorization control. This is something to which a penetration tester must pay attention. WebSockets, by themselves, don't provide any authentication or authorization control; this needs to be done at the application level.

Also, the connection implemented in the previous example is not encrypted. This means that it can be sniffed and/or intercepted through man-in-the-middle (MITM) attacks. The next screenshot presents a traffic capture with Wireshark showing the exchange between client and server:

The first two packets are the WebSockets handshake. After that, the message interchange starts. In this case, the client sends a name and the server responds Hello <NAME> :) How are you?. The data sent from client to server should be masked, as per the protocol definition (RFC 6455, http://www.rfc-base.org/txt/rfc-6455.txt), and the server must close the connection if it receives a non-masked message. On the contrary, messages from server to client are not masked, and the client closes the connection if masked data is received. Masking is not to be considered a security measure, as the masking key is included within the packet frame.