3

I'm making a webapp that uses WebSockets for communication between the browser and node server.

If you open up the debug console (F12), you can access the socket instance and write to it.

For example, socket.send('packetname', 'data')

What's stopping someone from opening the console and writing something like this?

socket.send(new Array(99999));

All this data being sent to the server can be overwhelming and by the time it gets there, the bandwidth is already used and it's already been processed. Of course there is validation but at that point it's too late and the resources have already been spent processing it.

You also can't just check the length of the array because someone could send an array where the first element is a huge array instead, or anything really. I don't think there's a way to calculate byte size so I guess the best option is stringifying the data to check its size (which is extremely slow)?

All my packets are very small. I am looking for a way of preventing packets over a certain size from being sent to the server. Is this possible?

Lawrence Douglas
  • 667
  • 1
  • 7
  • 15
  • can you made your socket inside something else to make it private – Daniel A. White Jun 17 '16 at 20:11
  • If you use [Socket.io](http://socket.io/) then tools like [`socket.io-stream`](https://www.npmjs.com/package/socket.io-stream) can be used to cut connections that are abusive. – tadman Jun 17 '16 at 20:20
  • @tadman: I'm using primus not socket.io – Lawrence Douglas Jun 17 '16 at 20:22
  • Don't use websocket's if you are worried about this. Restful and other services, have to send a Content-Length property. I apologize for this next part, my terminology and understanding in this area is fading. Websockets are used to be kept alive much longer than traditional Http protocols were designed to handle. Luckily, when the Http protocol hits it's max length, the servers discuss setting up another syn ack session. You could end it there! – Chris Clark Jun 17 '16 at 20:36
  • @user1438893: How do you measure the amount of bytes used in the message efficiently? – Lawrence Douglas Jun 17 '16 at 20:38
  • @LawrenceDouglas Sorry I deleted the comment and put it as an answer – pay Jun 17 '16 at 20:47

2 Answers2

1

Unless you have full control over the client (which you don't) you cannot hinder the client to send arbitrary large data to your system. The client would not even need to use a browser so any restrictions inside the browser will not work.

You just have to deal with it, like with disconnecting the client immediately if you get an unexpected amount of data and maybe blacklisting the origin so that the next attack attempt will be stopped earlier.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • The problem here is the client might be hostile and send, as an example, a never-ending array like `[0,0,0,0...` – tadman Jun 17 '16 at 20:23
  • @Steffen Ullrich: How would you even know you got a large amount of data? Do people stringify the packets and check the length or not even bother and just hope no one is abusive? My app is pretty casual so I doubt anyone would do anything but you never know. – Lawrence Douglas Jun 17 '16 at 20:23
  • @LawrenceDouglas: each websocket frame includes information about the total length at the beginning. So in theory one could detect messages which are too long before reading everything. Of course it is up to the framework if you can set such limits. – Steffen Ullrich Jun 17 '16 at 21:02
  • @SteffenUllrich: That sounds perfect. I wonder if there's a way to access that with Primus. – Lawrence Douglas Jun 17 '16 at 21:37
  • @LawrenceDouglas: from a short look I would say that primus abstracts is too much of an abstraction layer over various libraries and does not provide this level of configuration. It might be that you could pass options to the underlying library to get a more granular configuration. – Steffen Ullrich Jun 18 '16 at 04:25
1

There likely isn't any "best" solution to this. I would just think about things you can implement on the server side to detect if something like this might be happening. As far as stopping a client on the client side, it is difficult or maybe impossible to do that. Your server is designed to accept connections and data, so clients can attempt to exploit this.

One possible solution I can suggest is having an "upper limit" on how much data a client would send in a single operation. I don't know the nature of your application, but perhaps a client sending 2500 bytes of data in a single operation would be completely impossible given the nature of your app.

In this case, if an operation (bytes received) begins exceeding this upper limit, the connection can then be dropped.

This is only one potential solution I can think of, but you will need to come up with something along these lines.

pay
  • 366
  • 3
  • 18