53580 - Mozilla. transmits user/password in referal URL

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[Stephen Ostermiller]

If somebody visits a site protected with basic authentication using a url of the
form:
http://user:[e-mail]/
And they then proceed via link from siteA.domain to siteB.domain, the user and
password from siteA are transmitted to siteB via the referring URL.  In this
case the referring url that siteB sees is:
http://user:[e-mail]/

User and password data needs to be stripped from a URL before it can be used as
a referring URL.  Netscape 4 does this.  Using netscape 4 siteB would see:
http://siteA.domain/

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Woohoo - major information leakage. Thanks for noticing this; I'll fix it ASAP.
Marking nsbeta3.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

I tested this with Gagan, and it looks like we are filetring username:password
out of the referrer field. Marking WORKSFORME. Reporter, are you using a recent
build?

Comment 3

[Stephen Ostermiller]

The build I am currently using is:2000091212
(password is x'ed out here...)
If I visit http://webstats:[e-mail]/stats/
and then click around from there, I get a line that looks like this in my server
log:
10.2.1.55 - webstats [27/Sep/2000:07:40:39 -0400] "GET /stats/usage.png
HTTP/1.1" 200 2894 "http://webstats:[e-mail]/stats/" "Mozilla/5.0
(X11; U; Linux 2.2.5-15 i586; en-US; m18) Gecko/20000912"
With Netscape 4, I get "http://www.gcctech.com/stats/" reported in the server
logs as the user agent.

If I create a file called test.html in my stats directory which has a link to
http://www.gccprinters.com/ and access that and follow the links I get the
following two lines in my server logs:
10.2.1.55 - webstats [27/Sep/2000:07:49:51 -0400] "GET /stats/test.html
HTTP/1.1" 200 81 "-" "Mozilla/5.0 (X11; U; Linux 2.2.5-15 i586; en-US; m18)
Gecko/20000912"
10.2.1.55 - - [27/Sep/2000:07:49:59 -0400] "GET / HTTP/1.1" 200 1428
"http://webstats:[e-mail]/stats/test.html" "Mozilla/5.0 (X11; U;
Linux 2.2.5-15 i586; en-US; m18) Gecko/20000912"
(This should cover the case that mozilla is only stripping out the user and
password names when you go to a different domain, Mozilla shouldn't know that
www.gcctech.com and www.gccprinters.com are actually the same)

Let me do this test with the most recent nightly build.

Comment 4

[Stephen Ostermiller]

I couldn't get the latest nightly build for linux to start on my system.  I had
to resort to testing this in windows.  The latest nightly build still appears to
me to have this problem.  From my logs:
10.3.1.65 - webstats [27/Sep/2000:08:24:24 -0400] "GET /stats/test.html
HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Windows; U; Win98; en-US; m18)
Gecko/20000926"
10.3.1.65 - - [27/Sep/2000:08:24:28 -0400] "GET / HTTP/1.1" 200 1428
"http://webstats:[e-mail]/stats/test.html" "Mozilla/5.0 (Windows;
U; Win98; en-US; m18) Gecko/20000926"

Comment 5

[Stephen Ostermiller]

I created a page that makes it easy to test this problem.
See the URL now associated with this bug.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Reassigning to Gagan in case this problem actually still exists.

Comment 7

[Stephen Ostermiller]

Finally figured out how to start nightly builds under linux again.  Tested with
the latest nightly build by visiting:
http://mozilla:[e-mail]/test/
This bug is still here.

Comment 8

[Jarto Tarpio]

Confirming with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20000928

Comment 9

[Jesse Ruderman]

I see this on Windows 98 (not on the Ben&Jerry site, but I think that's because 
my proxy strips referers).  All/All.  Nominating for rtm.

Btw, bug 32359 also has a testcase that will show the referer.

Comment 10

[selmer (gone)]

Sounds like there's agreement that this problem really exists.  Seems like this
should be high priority and critical.  Gagan, Mitch, are either of you looking
at fixing this for RTM?  Is there some mitigating factor that makes this not
important?

Comment 11

[Gagan]

taking it over.

Comment 12

[Gagan]

Attachment: Fix that checks for prehost and skips it.

Comment 13

[Scott MacGregor]

sr=mscott

Comment 14

[Phil Peterson]

rtm++

Comment 15

[Gagan]

Attachment: Revised patch since ReplaceSubstring doesn't work yet!

Comment 16

[Gagan]

Attachment: Revised fix after scc's suggestion on Substring usage.

Comment 17

[Gagan]

Attachment: Final patch with scc's suggestions.

Comment 18

[Scott Collins]

sr=scc

Comment 19

[Gagan]

Fix checked in trunk as well as the branch.

Comment 20

[Gagan]

I had to back out my changes since Substring didn't turn out to be all that XP, 
had problems on AIX and Solaris. Am cc'ing scc for his suggestions on how to fix 
that. 

Comment 21

[Gagan]

Attachment: patch to fix AIX and Solaris bustage...

Comment 22

[Mike Kaply [:mkaply]]

Attachment: A little clean up - less casts

Comment 23

[Phil Peterson]

Gagan, did you back your fix out on the branch? Or just on the trunk? If this
fix is not on the branch, then it has missed the first N6 candidate build, so we
can not take it unless we respin. This bug is in candidate limbo.  We will
reconsider this fix once we have a candidate in hand, but we can't take this fix
before then. PDT marking [rtm+]

Comment 24

[Scott Collins]

sr=scc

Comment 25

[Gagan]

I had to back it out on the brance as wellas the trunk. Seems to me that I 
should go ahead and check this in but I'd wait for you/PDT to clear it. Thx.

Comment 26

[Phil Peterson]

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.

Comment 27

[Stephen Ostermiller]

Gagan -- looking at the patch code, you assume that the protocol is "http://" (7
characters long).  This bug would also show up under https (Any other protocols
have user/pass and send a referal?).  I believe that with your current fix, a
https://user:[e-mail]/ fail the assertion because "https://" has a
length of 8....

Comment 28

[Stephen Ostermiller]

Link to the test URL on using https:

https://mozilla:[e-mail]/test/

Comment 29

[Gagan]

Attachment: Final fix including the last suggestion

Comment 30

[Gagan]

Fix checked in

Comment 31

[Gagan]

asdf

Comment 32

[Scott Collins]

gagan, you got the cast wrong.  It's

  NS_READABLE_CAST(char, ref)

not |char*|

Comment 33

[Gagan]

ok fixed again. thanks scc and dcranford

Comment 34

[harishd]

On WinNT 2000-10-31-14-MN6 build this bug is fixed.

Marking VERIFIED.

Comment 35

[harishd]

Looks like we are not supposed to mark verified unless it's maked verified in
both branch & trunk.

Brach - 2000-10-31-14-MN6 - verified.

Comment 36

[harishd]

Added vtrunk to the keyword