WebSockets - Applied Review

What is a Web Socket?

#

WS (WebSockets) are widely used in modern web applications because they can initiate long-lived sessions over HTTP with asynchronous communication in both directions.

Most communication between browsers is done using HTTP, where the client side sends a request and the server replies with a response - this response is almost immediate and the transaction is finished.

WebSocket connections are initiated using HTTP but are long-lived and not designed to be transactional in nature, meaning the connection will stay open and idle until the client or server is ready for some message to be sent.

WebSockets are useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of data.

These connections are typically established by utilizing some client-side JS like this:

var ws = new WebSocket("wss://website.com/chat");

The wss protocol establishes a WebSocket connection over an encrypted TLS connection.

The browser establishes this connection by performing a WebSocket handshake over HTTP by first issuing a request like this:

GET /chat HTTP/1.1
Host: website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

If the server accepts this connection, it returns a handshake response like this:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

After this is done, the network connection remains open and can be used for sending WebSocket messages in either direction.

A message might be sent using JS like this:

ws.send("I love web sockets!");

These messages can contain almost any kind of data, but it is typical to see JSON being used to structure and send the data like this:

{"user":"Hal Ninek","content":"I am afraid I can't let you do that."}

These make it similar to HTTP in the context of how vulnerabilities may arise, but more useful depending on the application’s purpose.

Manipulating WebSocket Traffic

#

WebSocket security vulnerabilities often involve manipulating them in ways that the application is not designed to handle. We will mostly be utilizing Burp Suite to do those things, as there are features built in to the tool that make it easier for us.

Specifically, we can use Burp Suite to:

• Intercept and Modify WebSocket messages
• Replay and Generate WebSocket messages
• Manipulate WebSocket connections

WebSocket Security Vulnerabilities

#

As mentioned before, nearly any security vulnerability in HTTP can be found and exploited with WebSockets:

• User-supplied input can be processed in an unsafe way, leading to injection vulnerabilities
• Some WebSocket vulnerabilities may only be noticeable using blind-type attacks
• Attacker-controlled data being transmitted to users via WebSockets can lead to XSS or similar client-side vulnerabilities.

Exploiting WS Messages

#

Most input-based vulnerabilities found with WebSockets can be found by tampering with the contents of those messages being sent. Imagine a chat application that lets us send messages between a browser and some server.

We type a message and it is sent as a WebSocket message like this:

{"message":"Hello world!"}

The contents of this message might be transmitted again using WebSockets to some other user and get rendered in their browser:

<td>Hello world!</td>

You might be able to see how we could use this to exploit XSS on a victim’s browser just by sending them a message with the following contents:

{"message":"<img src=1 onerror='alert(1)'>"}

This example might be nasty because every time you visit the chat page, the JS will get executed.

Exploiting WS Handshakes

#

Some vulnerabilities will only be found after manipulating the initial handshake. These are usually because of design flaws like:

• Misuse of the X-Forwarded-For header
• Flawed session-handling mechanisms
• Custom HTTP headers used by the application

What is Cross-Site WebSocket Hijacking?

#

Cross-site WebSocket hijacking involves a CSRF vulnerability on a WebSocket handshake.

If the handshake relies solely on HTTP cookies for session handling and doesn’t use CSRF tokens or defenses, we can make a malicious webpage that establishes a WS connection on behalf of the victim user. Unlike conventional CSRF, we get a two-way kind of interaction with the vulnerable application.

Impact of CSWSH

#

Typically al the same things that we can do with CSRF depending on how WebSockets are used in the application. To sum it up, we can perform actions while pretending to be the victim user or retrieve sensitive data that the victim user would have access to.

This all depends on how the application is utilizing WebSockets though, it would need to use WebSockets for those actions to be vulnerable on top of the other conditions.

CSWSH Exploitation

#

Exploitation for this is basically the same as any other CSRF type attack, we would just need to set up our web page to send a WebSocket handshake on behalf of the victim user and route the response to our own machine to see the results.

Once that handshake is complete, then we can manually do back-and-forth communication with the target application if needed.

Prevention

#

To decrease the risk when using WebSockets, try to follow these guidelines:

• Use the wss:// protocol to make use of the TLS encryption it adds
• Hard code the URL of the WebSockets endpoint without incorporating user-controllable data
• Use CSRF protections when sending WS requests of any kind, especially the handshake
• Treat data received by WS as untrusted and sanitize it accordingly to prevent injection attacks