https://github.com/golang/go/issues/5082 and would appreciate some advice
on proper API exposure of extra parameter before submitting a CL.
The root cause of the issue is ioutil.ReadAll usage on a network
— this can be abused by client to take down server by exhausting its memory.
Most consumers of this package are likely using websocket.Codec struct
instances implementing custom message (un)marshalling; it is this struct's
Receive method that has this unbound ReadAll call.
My idea is to introduce an extra integer field to Codec struct, that would
specify max. size of payload that is allowed to be passed to Unmarshal
function (which receives byte). Codec's Receive method (the one that
calls Unmarshal) would then use something similar to io.LimitedReader over
the message payload if Codec has non-zero limit set; if this limit is hit,
Receive would return with reasonable error so websocket handler won't
allocate unbound amount of memory.
Package users expecting malicious input would then have to set this
threshold to some safe value. It would probably make sense to set this
field to some safe non-zero value for default predefined Codecs:
websocket.Message and websocket.JSON.
Before proceeding with CL, I would like to have some feedback on this
approach. Does this API change look reasonable? Is introducing a non-zero
payload size limit to predefined Codecs (Message and JSON) a good idea for
this particular case, provided that it would protect server from possible
denial of service, although having a chance of breaking existing programs
relying on current behavior (unlimited payload size)?
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.