Open FSMaxB opened 4 years ago
Correction: The channel lagged
error messages is coming from tokio::sync::broadcast
.
It would certainly be good to prevent this. First steps could include limiting the request body size with warp::filters::body::content_length_limit and throttling client's read stream with tokio::time::throttle.
I think the biggest problem at the moment is that the feed has an unlimited size. This probably also the reason why joining the chat doesn't work reliably in this scenario, because the client has problems receiving such a large response.
Another thing to look at: https://docs.rs/tungstenite/0.10.0/tungstenite/protocol/struct.WebSocketConfig.html (also used by tokio-tungstenite
). But after a quick look I didn't find a way to pass this configuration to warp
websocket filter.
max_frame_size was added in warp = "0.2.3"
.
Small proof of concept of a Denial of Service Attack:
My first thought was that I could just stop reading the responses from the server (
websocket.read_message()
) but then it seems liketokio-tungstenite
detects that and closes the connection:[2020-05-21T09:01:59Z ERROR rusty_chat::server] Client connection error: system error: channel lagged by 351
.Not reading the response and constantly trying to reconnect though is already enough to prevent other clients from joining.
When I start reading the responses as seen in the example above, the Feed will still fill up with messages until at some point the server will be killed because it uses too much memory.