Description

The Authorization header leaks from same hostname https-http redirect. If https://example.com redirects to http://example.com, then an attacker who can listen in on the wire (or perform a MITM attack) will be able to receive the Authorization header due to the use of the insecure HTTP protocol which does not verify the host the request is sending to. The attacker does NOT need to control example.com, they only need to able simply listen in on the wire (ability to perform MITM attack). A similar issue for PSF's (Python Software Foundation) requests module was filed in CVE-2018-18074

Vulnerable Code

In https://github.com/node-fetch/node-fetch/blob/81b1378bb3bda555d3d2114e7d3dfddbd91f210c/src/index.js#L204L208, it uses a isDomainOrSubdomain check to determine whether to send the confidential headers on redirect, but it does not validate that the scheme remains the same

Impact

If the attacker can intercept the HTTP request (perform MiTM attack) and https://example.com redirects to http://example.com, they may be able to leak the Authorization header during a same hostname/subdomain HTTPS-HTTP redirection. They do NOT need to control the hostname. There are 2 scenarios where this may occur:

1: A mistake occurs where the Authorization header is sent from HTTPS to HTTP (by a developer incorrectly specifying the HTTP protocol in the Location header) [for same hostname / subdomain-main domain redirection]

2: The malicious user controls the redirection target and sits in the middle of the network. If there are checks in place which allow one to control the redirection target (such as the hostname). Then this can open up a new possibility for the attacker to bypass the hostname check to send the credentials by the wire and sniff it, provided they exist in the same network.

Recommended Fix:

Check scheme of original URL and redirected URL for HTTPS-HTTP redirection and prevent it.