New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/net/websocket: allow configurable read size limit, and MaxHeaderBytes #5082
Comments
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. |
Codec's Receive method calls io.ReadAll of the whole frame payload, which can be abused by user sending large payloads in order to exhaust server memory. Introduce limit on received payload size defined by Conn.MaxPayloadBytes. If payload size of the message read with Codec.Receive exceeds limit, ErrFrameTooLarge error is returned; the connection can still be recovered if required: the next call to Receive would at first discard leftovers of previous oversized message before processing the next one. Fixes golang/go#5082. Change-Id: Ib04acd7038474fee39a1719324daaec1c0c496b1 Reviewed-on: https://go-review.googlesource.com/23590 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
The text was updated successfully, but these errors were encountered: