Exposure of Sensitive Information to an Unauthorized Actor in follow-redirects/follow-redirects

Valid

Reported on

Feb 8th 2022


Note

Reclarification of https://huntr.dev/bounties/6d9fd2bf-39e4-4291-b228-30f131b9ccdc/

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 hostname 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 vulnerability for PSF's (Python Software Foundation) requests module was filed in CVE-2018-18074

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 HTTPS-HTTP redirection. They do NOT need to control the hostname.

Recommended Fix

Implement same schema check (at least prevent leaking authorization header in HTTPS-HTTP redirection).

We are processing your report and will contact the follow-redirects team within 24 hours. 4 months ago
haxatron modified the report
4 months ago
haxatron modified the report
4 months ago
haxatron modified the report
4 months ago
Ruben Verborgh validated this vulnerability 4 months ago
haxatron has been awarded the disclosure bounty
The fix bounty is now up for grabs
haxatron
4 months ago

Researcher


Though this has already been marked as valid, I would like to share my rationale on whether this is realistic. I can think of 2 scenarios (as I was already typing this in the other thread):

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). I believe that this is similar chance of occurring as the Cookie header being sent to a cross-domain redirect, where the chances of a browser-based protection, is mistakenly sent to a third-party domain (by a developer incorrectly specifying the third-party domain in the Location header)

2: An open redirection vulnerability where a 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, provided they exist in the same network.

I expect these two scenarios to be rare but possible to occur.

Ruben Verborgh confirmed that a fix has been merged on 62e546 4 months ago
Ruben Verborgh has been awarded the fix bounty
index.js#L396L398 has been validated
Ruben Verborgh
4 months ago

Maintainer


Thank you, @haxatron!

haxatron
4 months ago

Researcher


@admin can the CVSS be lowered to 3.1 - CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

haxatron
4 months ago

Researcher


Actually, 2.6 - CVSS:3.0/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Jamie Slome
4 months ago

Admin


Score updated from 4.2 to 2.6! 🎉

haxatron
4 months ago

Researcher


A side note: I noticed that RFC 7235 Section 2.2 mentions protection spaces (scheme+authority) for authentication realms, not specifically for redirection [I brought this RFC up as it was discussed in https://github.com/psf/requests/pull/4718 . But then again, there was never any RFC mentioning the stripping of sensitive headers for redirects in general.

Given that the definition of an origin in the Same-Origin-Policy refers to (scheme+host+port), I believe that it is right that this change should be enacted to follow the SOP and to resolve the 2 scenarios above. Additionally, some clients do implement the same scheme check: PSF's requests (they make an exception for HTTP-HTTPS redirection though), urllib3 and Square's OkHTTP.

Ruben Verborgh
4 months ago

Maintainer


It's puzzling how little the RFCs say about correct redirection behavior. Also unclear what to do with unknown headers, for instance.

to join this conversation