Exposure of Sensitive Information to an Unauthorized Actor in follow-redirects/follow-redirects
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).
Occurrences
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.
@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
Actually, 2.6 - CVSS:3.0/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
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.
It's puzzling how little the RFCs say about correct redirection behavior. Also unclear what to do with unknown headers, for instance.