Exposure of Sensitive Information to an Unauthorized Actor in node-fetch/node-fetch

Valid

Reported on

Feb 12th 2022


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.

We are processing your report and will contact the node-fetch team within 24 hours. 3 months ago
haxatron modified the report
3 months ago
haxatron modified the report
3 months ago
haxatron modified the report
3 months ago
haxatron modified the report
3 months ago
haxatron modified the report
3 months ago
haxatron modified the report
3 months ago
We have contacted a member of the node-fetch team and are waiting to hear back 3 months ago
We have sent a follow up to the node-fetch team. We will try again in 7 days. 3 months ago
node-fetch/node-fetch maintainer validated this vulnerability 3 months ago
haxatron has been awarded the disclosure bounty
The fix bounty is now up for grabs
Jimmy Wärting confirmed that a fix has been merged on 1ef4b5 3 months ago
Jimmy Wärting has been awarded the fix bounty
haxatron
3 months ago

Researcher


Hi @maintainer commit 1ef4b5 does not fix this

Jamie Slome
3 months ago

Admin


@haxatron - can you share which commit fixes this?

haxatron
3 months ago

Researcher


@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)

haxatron
3 months ago

Researcher


Jamie Slome
3 months ago

Admin


I have paused the automatic publishing of the CVE until was have this rectified as well.

to join this conversation