Poking holes in your applications with WebSockets

According to MDN web docs, WebSockets makes it possible to open two-way communication (full-duplex communication) between a client and a server without the client asking the server again for a response. The most common applications WebSockets are used for are ones that communicate data in a constant stream without querying the server subsequently for responses. These applications include: Client to client communications such as chat, Monitoring, and maintenance Human Machine Interfaces (HMI) that are used in Industrial Control Systems (ICS) or other SCADA networks, multiplayer games — the list goes on.

The great thing about WebSockets is that most browsers support them natively. The BeEF Framework’s core is built around this protocol in order to keep the victim browser “hooked” into your C&C. Think about it, full duplex communication AND it’s native in all browsers since IE 10? A web security researcher’s wet dream if you ask me.

The initiation of full-duplex WebSocket communication starts with the following request and response:

There are some things that just get thrown out the window when this Handshake occurs. In terms of Authentication and Authorization, there is no implementation in WebSockets to enforce these policies besides the practices that HTTP uses (Basic Auth, Cookies and the like). You can always use you headers such as Origin, User-Agent, and IP address to authenticate but these can easily be manipulated.

Out of the box, they are not secure at all. There are a multitude of vulnerabilities that can occur with WebSockets such as replay attacks, spoofing, buffer overflows, and sniffing. There can be things that may invoke a buffer overflow, such as parameters that may be send along the connection.

Unencrypted communications such as HTTP suffer from sniffing attacks, WebSockets are no different when using ws:// as a method of transfer. Tools such as Wireshark and tcpdump can easily sniff out the unencrypted traffic.

To prevent sniffing attacks WebSockets included WebSockets over TLS/SSL (wss://), this idea is similar to HTTP and HTTPS.

WebSockets use standard HTTP headers for authentication and authorization. It’s common to look at the Origin header and setup session tokens for authenticated requests. This is how WebSockets authenticate a valid session. Things like a wildcard CORS are it’s worse nightmare as it allows anyone outside of it’s origin to establish connections with the socket. The problem with having an origin only header to authenticate a connection is that it can be easily tampered with.

The tragedy of WebSockets and their infancy shows in CORS and SOP, both are not implemented as strictly as they are with HTTP and HTTPS connections. Due to this reason you can effortlessly establish a connection with a server outside of your origin. On the server-side, you will need to implement a feature such as a nonce or adding metadata information such as timestamp, IP, and/or user ID to ensure the request is genuine BEFORE the WebSocket upgrade.

Securing the establishment of the connection is one thing but how can we take it a step further to protect the assets the client is talking to? Applications that are deploying WebSockets are going to be interfaced with on a regular basis, so authorization past authentication needs to be deployed.

Sure, you can throw on a cybersecurity silver bullet solution to secure WebSockets, but the brittle foundation in which the internet has built itself on is crumbling. It will not surprise me if the next “big” 0-day exploit is related to this technology.

Thank you for reading

— 💮💀💮

Related posts:

Good news! My husband has finally started his part-time job. He is running the pro-shop at the local Air Force Base golf course. He gets to eat lunch right there at the snack bar with our son, the…

How to get paid for guest posts. Steps to identify blogs, save, research, and then write a successful pitch.

As I go deeper into the tech/venture arena, I often find myself as the lone women in rooms full of men. To my core, I am what many would consider a girls’ girl. I — not so jokingly — joke that if I…