Описание
CRLF injection in Refit's [Header], [HeaderCollection] and [Authorize] attributes
Summary
The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection.
Details
The way HTTP headers are added to a request is via the HttpHeaders.TryAddWithoutValidation method: https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328
This method does not check for CRLF characters in the header value.
This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.
PoC
The below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the "Authorization" header:
This application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):
The application intends to send a single request of the form:
But as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:
and
This can be confirmed by checking the access logs on the server where these commands were run (with insert.some.site.here pointing to localhost):
Impact
If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.
Strictly speaking this is a potential vulnerability in applications using Refit, not in Refit itself, but I would argue that at the very least there needs to be a warning about this behaviour in the Refit documentation.
Ссылки
- https://github.com/reactiveui/refit/security/advisories/GHSA-3hxg-fxwm-8gf7
- https://nvd.nist.gov/vuln/detail/CVE-2024-51501
- https://github.com/reactiveui/refit/commit/483b1d8df18098f137ca0eca056b7e9ec19f70dd
- https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328
Пакеты
Refit
< 7.2.22
7.2.22
Связанные уязвимости
Refit is an automatic type-safe REST library for .NET Core, Xamarin and .NET The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection. The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method. This method does not check for CRLF characters in the header value. This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request