Different SRC vulnerability discovery approach： Practical case of HTTP request splitting vulnerability

Some experts say that it is impossible to find HTTP request smuggling, splitting, or web cache poisoning in China. This is because for a long time, there have been very few experts sharing practical cases of such vulnerabilities in China, and almost all practical cases come from abroad, creating a misconception that such vulnerabilities do not exist in China.

But the actual situation is not like that. In 2023, I have found many interesting vulnerabilities related to HTTP requests, and the cumulative bounty for these vulnerabilities is not less than 100,000 yuan. I can firmly say that the statement 'It is impossible to find HTTP request smuggling, splitting, or web cache poisoning in China' is not correct. Today, I will share with everyone a high-risk practical case of a domestic SRC that I dug up before: a high-risk practical case of HTTP request smuggling caused by HTTP request splitting.

I. The Beginning of the Story

One day, I found that a certain site has a request splitting vulnerability caused by CRLF injection, but after a series of explorations, I found that the upstream server is not a bucket, but a reverse proxy configured with request forwarding based on Host.

Through the results of black-box testing, I guess the architecture of the site may be similar to the following form:

client ----> reverse proxy 1 --CRLF--> reverse proxy 2 --Host--> (web server 1 | web server 2 | web server 3 | ...)

When reverse proxy 1 forwards the request to the upstream reverse proxy 2, CRLF injection occurs. After receiving the request message, reverse proxy 2 forwards the request message to the corresponding web server according to the Host request header of the request message.

For example:

Host:case.target.com ----> web server 1

Host:www.target.com ----> web server 2

Host:user.target.com ----> web server 3

...

The interesting point of this case is that the communication between reverse proxy 1 and reverse proxy 2 supports pipeline.

That is to say: Reverse proxy 1 can send multiple HTTP request messages to reverse proxy 2 at one go:

step1. Reverse proxy 1 ----> HTTP request message 1 ----> Reverse proxy 2

step2. Reverse proxy 1 ----> HTTP request message 2 ----> Reverse proxy 2

step3. Reverse proxy 1 ----> HTTP request message 3 ----> Reverse proxy 2

...

without waiting for the corresponding response message for each send:

step1. Reverse proxy 1 ----> HTTP request message 1 ----> Reverse proxy 2

step2. Reverse proxy 1 blocks and waits for the corresponding response message from reverse proxy 2

step3. Reverse proxy 1 ----> HTTP request message 2 ----> Reverse proxy 2

step4. Reverse proxy 1 blocks and waits for the corresponding response message from reverse proxy 2

...

It is precisely because of this feature that I found that when I inject HTTP request messages through CRLF injection to smuggle HTTP requests, the reverse proxy 1 seems to merge multiple response messages received from the upstream server into a single response message and return it to me:

https://case.target.cn/%20HTTP/1.1%0d%0aHost:case.target.cn%0d%0a%0d%0aPOST%20/%3fid=%20HTTP/1.1%0d%0aHost:targ