Be careful when using websockets!

I was playing skribbl.io with a couple of my friends the other day, and I decided to download this Chrome extension called AutoDraw for skribbl.io. Basically, what it would do is you drag and drop in an image, and then it would automatically draw your super awesome image onto skribbl.io. I was having a lot of fun playing around with this extension, so I decided to check out what was going on under the hood. 

It turns out that skribbl.io actually opens up a websocket connection from your browser to their server (mine was probably located somewhere probably in France (the IP belonged to OVH and the ping was 18ms from both London and Amsterdam) and it was sending my mouse movements every 50ms to the server in 195 byte messages. For those keeping count at home, this is around 0.0312 Mbps that I have to pay. Now, my friends in the game were also receiving these 0.0312 Mbps from the server to their browsers, free of charge. 

If we had max-ed out the room to the size limit of 12 players (which unfortunately we didn't do because we are bad at coordinating these fun activities 😢), we would have been able to use 0.0312 Mbps to force skribbl.io to expend 0.3432 Mbps sending my mouse movements to all my friends, which is a bandwidth amplification factor of 11! This obviously is pretty tiny and probably won't be putting skribbl.io at any risk, but maybe this should bring to our attention a problem that is prevalent in a lot of applications that use websockets?

When we build websocket applications like skribbl.io where we need to take events emitted from one client and broadcast them to other subscribing clients, are we creating a system that is inversely supported by economics, as Dr. Fielding once said? At the end of the day, skribbl.io feels like an application that follows the event-based integration (EBI) architectural style. EBI scales nicely when there are many more event sources than recipients of event notifications, say, if there were many drawers and few guessers in skribbl.io. But then when there are few event sources and many event notification recipients, EBI scales much worse and opens up for denial of service attacks. Maybe this is why skribbl.io limits rooms to 12 players? If they allowed for, say, 100 players in one room, they'd have to expend bandwidth that is 100 times my bandwidth just to broadcast my drawing to all the other players, which might allow them to be DDoS'ed by a malicious coder opening a bunch of private rooms, with the drawer being a real open websocket constantly transmitting mouse movements at max bandwidth, and the other players being just a bunch of websocket connections leading to places with low or no download bandwidth...

While this might be a bit controversial, I think a solution to this could be to implement some form of polling in websockets. Perhaps to receive your 195 byte message containing the drawer's mouse movements, you must burn 195 bytes? You could also create some sort of system where if you begin by pre-burning, say, 195×10 bytes, and then you would earn enough "credit" to receive the next 10 messages. And as you receive these messages, you burn more bytes to replenish more tokens to receive future messages. This would achieve the goal of preventing a DDoS attack of the form described above by balancing the server's bandwidth obligations with the client's bandwidth obligations. But then, it might also defeat one of the purposes of websockets in the first place: to reduce wasted overhead. But maybe this trade-off is worth it for the security?

Comments

Post a Comment

Popular posts from this blog

First-Principles Derivation of A Bank

What is a Bank? A bank borrows money from people with money but low-risk appetite, and lends money to people who need money to take potentially rewarding risks. Say we live in a toy society with $10 in circulation and 2 people (a farmer and a cook). In this society, the farmer grows vegetables and the cook processes vegetables for food – both activities essential for survival. Assume that both parties start with $5 each. The farmer sells vegetables for $1 per serving and can produce 2 servings per day. The cook prepares food for $2 per serving and also has the capacity to produce 2 servings per day. Every day, the farmer sells 2 servings of vegetables to the cook for a total of $2 . Then, the cook prepares 2 servings of food and sells 1 serving to the farmer for $2 . In this perfectly balanced society, everybody eats, and money never needs to “rest.” Let's break the above equilibrium by adding a time component. In this society, vegetables take thr...
Read more

A Play-by-play of the Mirai botnet source code - Part 1 (scanner.c)

Today I've decided to start learning something very new and unfamiliar to me, as someone who mostly works with very high-level languages like Python and Kotlin, and attempt to understand the source code behind the Mirai botnet that managed to control over 380,000 IoT devices at one point in its life. I'll likely get a lot of things wrong the first time around, and this may take quite a few blog posts to complete, but my goal is to document everything I figure out, so that in the future, someone else in a similar position will be able to use this blog as a resource to understand the C and Go that ran this ground-breaking botnet. To begin, I'll start by reading  scanner.c , which is the code that is in charge of the scanning for and infecting new IoT devices. I'll be taking my time with it, so this might take a few blog posts. scanner.c  has most of its logic in a function called  scanner_init , which is triggered either from  main.c  (which seems like how it is t...
Read more

You can control individual packets using WinDivert!

Image
WinDivert is one of the most interesting packages I've recently come across. What WinDivert allows you to do is apply a filter to grab some subset of packets that pass through your Windows computer, and then apply some logic to the packet to maybe modify, and then drop or re-inject the packet. Here's a great diagram from this website that sums it up: Using PyDivert , a WinDivert Python binding, we can specify the PROGRAM portion in the above diagram, which means that we can now capture whatever packets we want, change them however we want, and then either drop them or re-inject them to be sent out whenever we want. The big sell here is that WinDivert allows you to play with packets on Windows without writing code that modifies the core operating system components that run in the kernel! The drawback is of course speed and efficiency, but for a lot of blog-post-worthy applications, we don't need that much speed and efficiency. Stay tuned for more stuff if this piqued your ...
Read more