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
The above code doesn't make any sense because it essentially says
Read as many bytes as you want into memory
This of course can lead to very bad scenarios because the content-length is controlled by the attacker. Furthermore, it's a lot of code to spell the ~equivalent of
And just to be clear, we do not have to check content-length here. The content length is correct, or else NIO would've spotted that and sent an error instead (like illegal EOF condition if it ended prematurely or so).
But let's get to fixing this:
Goals:
Reasonable (fixed-sized limit) code should look good and be discoverable without reading much documentation
Unreasonable code should be possible but awkward using some word that conveys the danger of what's happening
Not overcomplicated
Ideas:
Put a reasonable default limit (e.g. 4MB) on there. So body.collect() would be safe
Make it clear in the docs that streaming should always be preferred. For example to save something to disk or proxy it, collect(...) should not be used. Only for JSON/protobuf/image/... decoding that needs to happen in memory we should use it
Instead of Int use a new type that can be constructed with integer literals or (and thanks to @hamzahrmalik for the idea) using some .init(watchOutWhatYourAreDoingIsDangerous: Int)
Maybe
body.collectIntoMemory() -- safe: up to 4 MB
body.collectIntoMemory(maximumSize: .megabytes(16)) -- safe: up to 16 MB
body.collectIntoMemory(maximumSize: .bytes(contentLength)) -- compiler error: expected type BodySize, actual type Int
body.collectIntoMemory(maximumSize: .bytes(BodySize(dangerousCalculatedSizeInBytes: contentLength)) -- unsafe but compiles
The text was updated successfully, but these errors were encountered:
We see code similar to this a lot
The above code doesn't make any sense because it essentially says
This of course can lead to very bad scenarios because the
content-length
is controlled by the attacker. Furthermore, it's a lot of code to spell the ~equivalent ofAnd just to be clear, we do not have to check
content-length
here. The content length is correct, or else NIO would've spotted that and sent an error instead (like illegal EOF condition if it ended prematurely or so).But let's get to fixing this:
Goals:
Ideas:
body.collect()
would be safecollect(...)
should not be used. Only for JSON/protobuf/image/... decoding that needs to happen in memory we should use itInt
use a new type that can be constructed with integer literals or (and thanks to @hamzahrmalik for the idea) using some.init(watchOutWhatYourAreDoingIsDangerous: Int)
Maybe
body.collectIntoMemory()
-- safe: up to 4 MBbody.collectIntoMemory(maximumSize: .megabytes(16))
-- safe: up to 16 MBbody.collectIntoMemory(maximumSize: .bytes(contentLength))
-- compiler error: expected typeBodySize
, actual typeInt
body.collectIntoMemory(maximumSize: .bytes(BodySize(dangerousCalculatedSizeInBytes: contentLength))
-- unsafe but compilesThe text was updated successfully, but these errors were encountered: