Closed Bug 220122 Opened 21 years ago Closed 21 years ago

Proxy-Authentication credentials can be exposed to origin server

Categories

(Core :: Networking: HTTP, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.6alpha

People

(Reporter: darin.moz, Assigned: darin.moz)

Details

(Keywords: fixed1.4.2, fixed1.5)

Attachments

(1 file)

SUMMARY Proxy-Authentication credentials can be exposed to an origin server if the origin server issues a 407 response. ORIGINAL REPORT -------- Original Message -------- Subject: - Unix: x86 Linux (2.4.19) - Proxy authentication credentials leak Date: 2003-09-05, 20:33 From: llmora@gibnet.gi To: security-flaw@netscape.com Submitter name: Lluis Mora Submitter email address: llmora@gibnet.gi Acknowledgement checkbox: on Product: Netscape 7.x Operating system: Unix: x86 Linux OS version: 2.4.19 Issue summary: Proxy authentication credentials leak Issue details: In a setup where the user is accessing the network directly without a proxy server, if an origin HTTP server replies to a request with a "407 Proxy authentication required" status (such as a server protected by a reverse proxy requiring authentication), Netscape will prompt the user to "Enter username and password for proxy at". Once the user fills in the username and password, his credentials are cached and bound to the "realm" of the "Proxy-Authenticate" header. After this, if another HTTP server (different IP or FQDN) sends a 407 response with the same "realm" as the one set by the original server, Netscape retrieves the user credentials from the cache and sends them to the rogue server without prompting the user for a different set of credentials, thus leaking the authentication information of the original server to the rogue server. Practical scenario ------------------ Trusted site: www.trusted.com Attacker site: www.attacker.com This is the step by step process to reproduce it: 1. The user sends a request to www.trusted.com: GET / HTTP/1.0 Host: www.trusted.com 2. The server (or a proxy in front of it) replies with a 407 status message: HTTP/1.0 407 Proxy Authentication required Proxy-Authenticate: Basic realm="TEST" 3. At this point, Netscape prompts the user for a proxy username and password. Once the user fills in the details, Netscape sends proxy authentication credentials to the server: GET / HTTP/1.0 Host: www.trusted.com Proxy-Authorization: Basic dWxhbGFsOmpzanNqc2pz ------------------ 4. Later on, the user decides to visit www.attacker.com and sends a request (separate connection, different IP address/port): GET / HTTP/1.0 Host: www.attacker.com 5. The attacker server replies with a 407 status message, setting the SAME REALM as the trusted website: HTTP/1.0 407 Proxy Authentication required Proxy-Authenticate: Basic realm="TEST" 6. Instead of prompting the user for a username and password, Netscape automatically sends a request with the credentials originally submitted to www.trusted.com: GET / HTTP/1.0 Host: www.attacker.com Proxy-Authorization: Basic dWxhbGFsOmpzanNqc2pz And thus the attacker gets hold of the username and password to access www.trusted.com. Additional computer info: Tested on Netscape 7.1 running on a Linux 2.4.19 (slackware 9) with libc6, although this seems to be a platform independent HTTP protocol implementation error. This form was submitted from http://help.netscape.com/forms/bug-security.html?cp=bbpctr with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1.
Attached patch v1 patchSplinter Review
this patch causes the origin server domain to be used whenever a 407 results from a non-proxy http request.
Attachment #132012 - Flags: superreview?(dveditz+bmo)
Attachment #132012 - Flags: review?(dougt)
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.6alpha
Flags: blocking1.6a?
Flags: blocking1.5?
Flags: blocking1.4.2?
need reviews and comment on this quickly if we are going to try and get it in 1.5
Comment on attachment 132012 [details] [diff] [review] v1 patch sr=jst
Attachment #132012 - Flags: superreview?(dveditz+bmo) → superreview+
Comment on attachment 132012 [details] [diff] [review] v1 patch r=bzbarsky
Attachment #132012 - Flags: review?(dougt) → review+
Attachment #132012 - Flags: approval1.5?
Comment on attachment 132012 [details] [diff] [review] v1 patch a=chofmann for 1.5
Attachment #132012 - Flags: approval1.5? → approval1.5+
fixed trunk and 1.5 branch
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed1.5
Resolution: --- → FIXED
Flags: blocking1.6a?
Flags: blocking1.5?
Can someone get this into the 1.4 branch? I'll approve the patch next. /be
Flags: blocking1.4.2? → blocking1.4.2+
Comment on attachment 132012 [details] [diff] [review] v1 patch a=brendan@mozilla.org -- this is the last security bug opened (because fixed in 1.5) that should be fixed for 1.4.2, I believe. /be
Attachment #132012 - Flags: approval1.4.2+
darin: Can you put this on MOZILLA_1_4_BRANCH please? Thanks
fixed1.4.2 ... hmm, no keyword by that name. should there be a fixed1.4.2 keyword?
adding keyword per previous comment
Keywords: fixed1.4.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: