You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently trying to find a solution for the issues #60 and #149. They are more serious than one might expect: Whenever a server blocks on receive a client can send an arbitrary large message and easily exhaust the servers memory.
While reviewing the code I noticed that RFC 6455 (section 5.5) mandates that control frames are never fragmented and their payload does not exceed 125 bytes. I found that this is not enforced by the current implementation allowing an attacker to even bring down a server with a PING or CLOSE frame.
I prepared a PR enforcing these properties in the decoder.
The text was updated successfully, but these errors were encountered:
lpeterse
pushed a commit
to lpeterse/websockets
that referenced
this issue
Jun 28, 2017
I'm currently trying to find a solution for the issues #60 and #149. They are more serious than one might expect: Whenever a server blocks on
receive
a client can send an arbitrary large message and easily exhaust the servers memory.While reviewing the code I noticed that RFC 6455 (section 5.5) mandates that control frames are never fragmented and their payload does not exceed 125 bytes. I found that this is not enforced by the current implementation allowing an attacker to even bring down a server with a PING or CLOSE frame.
I prepared a PR enforcing these properties in the decoder.
The text was updated successfully, but these errors were encountered: