Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
x/net/websocket: allow configurable read size limit, and MaxHeaderBytes #5082
Comments
mikioh
changed the title
mikioh
changed the title
rsc
changed the title
|
This actually is a tragic failing. It means that Go websockets cannot be used safely in an unprotected network, since malefactor can simply request a giant message to DoS your service. |
|
Bump. This is a SECURITY FAILURE. Its a trivial remote DoS for websocket, meaning that you should not use native Golang websockets pretty much anywhere. |
|
In fact, this is probably the only reason that I have to use 3rd party Gorilla websocket instead of native golang one. Which angers me as the Gorilla folks have busted compatibility for Go versions < 1.5 recently. |
|
One option to limit incoming payload size can be introduction of optional "max.received message payload size" field to websocket.Codec struct, which, if non-zero, should be treated by Codec.Receive method as indication to wrap frame io.Reader into something similar to io.LimitedReader (that also has to report ErrUnexpectedEOF to recognize incomplete reads) right before the call to ioutil.ReadAll, which is a culprit here. |
|
Anybody want to send in a fix? If you are unsure about the approach, discuss on the golang-dev mailing list first. |
|
@ianlancetaylor will open a mailing list thread then, ready to get my hands on this. |
|
Yay! Glad to see progress here! On Mon, May 30, 2016 at 12:08 PM, Artyom Pervukhin <notifications@github.com
|
|
CL https://golang.org/cl/23590 mentions this issue. |
What steps will reproduce the problem? Currently go.net/websocket provides no way to limit how much data an websocket server reads, if an client sends very large amounts of data (messages, frames) the websocket server will allocate that memory, and will continue to do so, until the server runs out of memory or the client crashes. [In someone else's tests] it has been observed that there is also no header limit provided (for the same issue). (See discussion: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/2Tge6U8-QYI) What is the expected output? go.net/websocket should provide an way to set an maximum read size and maximum header read size, to avoid attacks from potentially malicious clients.