Possible request smuggling in HTTP/2 due missing validation
Description
        Reviewed
      Mar 9, 2021 
    
  
        Published to the GitHub Advisory Database
      Mar 9, 2021 
    
  
        Published by the National Vulnerability Database
      Mar 9, 2021 
    
  
        Last updated
      Aug 16, 2023 
    
  
Impact
If a Content-Length header is present in the original HTTP/2 request, the field is not validated by
Http2MultiplexHandleras it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1.If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (
HttpRequest,HttpContent, etc.) viaHttp2StreamFrameToHttpObjectCodecand then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.
An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:
Users are only affected if all of this is
true:HTTP2MultiplexCodecorHttp2FrameCodecis usedHttp2StreamFrameToHttpObjectCodecis used to convert to HTTP/1.1 objectsPatches
This has been patched in 4.1.60.Final
Workarounds
The user can do the validation by themselves by implementing a custom
ChannelInboundHandlerthat is put in theChannelPipelinebehindHttp2StreamFrameToHttpObjectCodec.References
Related change to workaround the problem: Netflix/zuul#980
References