CRLF injection in Proxy-Authorization header built from proxy_auth_fun in hackney

Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackney_http_connect in benoitc hackney allows HTTP Request Splitting via the value a proxy_auth_fun callback returns. After a 407 response from an HTTP CONNECT proxy, hackney_http_connect:handle_proxy_auth/11 calls the caller's proxy_auth_fun with the status code and the response headers and writes the returned binary into the Proxy-Authorization line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.

The value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.

This issue affects hackney: from 2.0.0 before 4.9.0.

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.