Exposure of Sensitive Information to an Unauthorized Actor in node-fetch/node-fetch
Feb 12th 2022
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
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
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.
Check scheme of original URL and redirected URL for HTTPS-HTTP redirection and prevent it.
Hi @maintainer commit 1ef4b5 does not fix this
@haxatron - can you share which commit fixes this?
@maintainer, a note here that this issue is different from https://nvd.nist.gov/vuln/detail/CVE-2022-0235, this issue talks about sensitive header leakage from HTTPS domain / subdomain to same HTTP domain / subdomain, whereby an attacker is able to gather the sensitive headers if they can listen in on the wire (perform MiTM)
I have paused the automatic publishing of the CVE until was have this rectified as well.
@hexatron can we confirm whether this commit fixes the vuln?