HTTP/1.1 and HTTP/2 redirects resend basic_auth and cookie to a different scheme or port in hackney

Summary

Insufficiently Protected Credentials vulnerability in hackney in benoitc hackney allows a redirecting server to obtain the basic_auth and cookie credentials of a request via a same-host redirect to another scheme or port. With follow_redirect enabled, hackney:follow_redirect/10 in src/hackney.erl reissues the request to the Location target after hackney:maybe_strip_auth_on_redirect/3, which compared only the hostname of the current and the redirect URL. A redirect from https to http on the same host resent the Authorization and Cookie headers in cleartext, where an on-path attacker can read them, and a redirect to another port on the same host handed them to a different service. location_trusted forwards credentials to any target by design and is unchanged.

This issue affects hackney: from 2.0.0 before 4.9.0.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.