Abusing Hop-by-Hop Header to Chain A CRLF Injection Vulnerability
This blog post explores a CRLF injection vulnerability in the
Location header of an HTTP response and how it could be used to chain it with other attacks.
I found a CRLF injection vulnerability in the
Location header of an HTTP response. This vulnerability can allow the attacker to perform various actions such as open redirect, setting cookies, and arbitrary headers.
Most clients won’t consume the body in a redirect response. To exploit this CRLF injection further, the attacker needs to find a way to get rid of the
Location header. Removing the
Location header allows the attacker to fully control the body of the HTTP response. This would make it possible to chain the CRLF injection vulnerability with other vulnerabilities like SSRF and XXE.
After spending some time on this, I remembered a post by @nj_dav about abusing hop-by-hop headers. You can find the post here https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers.
In my case, the attacker can use the CRLF injection to set the hop-by-hop header
Connection in the response and setting the value to
Connection: Location, close. An intermediary proxy that is present in this specific case will consume the CRLF injected response and process the injected
Connection header, ultimately removing the
The status code of the HTTP response is still
302 but it is treated as
200 response if the
Location header is missing.
I’ve chosen a simple XSS to demonstrate that we are able to set arbitrary content in the response and make clients consume the response.
Our injected exploit does the following:
Connection: Location, close.
text/html(needed for my specific target).
- Set an appropriate
Content-Lengthheader to ensure that clients correctly parse the HTTP response and discard any trailing data.
- Inject payload in the body of the response.
URL encoded exploit
The response as seen by clients
While I wasn’t able to successfully chain this vulnerability with others, it’s important to note that even well-known vulnerabilities can have additional attack surfaces that should be identified and addressed.