How HTTP Request Smuggling Still Exist and How to exploit

There are still many new websites which uses HTTP/2 from the client to the CDN or WAF, but still in back-end server, they downgrade from HTTP/2 to HTTP/1.1 due to their massive deployment. The main reason for this Vulnerability to still exist is that they need to change the huge deployment, upgrading from HTTP/1.1 to HTTP/2 which is hard due to the binary framing complexity, multiplexing overhead and strict encryption requirements. Upgrading the deep internal legacy servers like Apache, Node.js, Tomcat, WSGI and some micro-services don't support HTTP/2 protocol. Some companies lack Public Key Infrastructure (PKI) which is needed to set-up the private micro-services and establish SSL, TLS Handshakes. maintaining thousands of this, is overhead. Here when i was hunting for Vulnerability, I found a Classic HTTP request Smuggling CL-TE. which tends to send two request as one, and receiving two responses as a one appending at the end of the first response. if you can't understand this, lets go through my hunt,

• I started testing on a POST request on /api/graphql Endpoint.
• Just for name-sake tried a CL-TE by setting the content-length to the full length of the body, and setting the Transfer-Encoding : chunked, and set a small length in HEX, termination with 0.
• Here the Front-End server see the Content-Length and Passes the Smuggled Request as a Body.

• You can see, there will be Content-Length header with full length of the body, and Transfer-Encoding: chunked, setting the size exactly the length of the query (in Hex)and terminating with 0.
• As I said before, the front-end see the content-length and passes the whole body request to the back-end.
• The back-end server, it see the transfer-encoding and terminates the body. so the request was ended with the 0. but there is still one more request which we smuggled.
• this smuggled request will be ran in back-end. note that the content length was not fully read. here is the trick. after completing the body with 0, still the content length works here. the server process the 2nd request and the response is attached to the legit request we sent.
• this results in the appending of two response body into one.

Impact :

• This is being used for many attacks like :

1. Appending other users data into our own session
2. making the request cache with redirecting to your attacker-controlled domain.
3. this smuggling bypasses WAF and lets you do actions in internal server, which is being blocked by the WAF.
4. combining reflected XSS with this smuggling.
5. Denial of Service (DoS)

To be noted, these bugs are till on many legacy servers, making this exploit severity increasing. best practice is to upgrade from HTTP/1.1 to HTTP/2