82479 - HTTP Referer: for SSL page should not be sent to insecure page

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[Terry Hayes]

We need to verify that the HTTP protocol engine does NOT send a Referer: field
for HTTP requests that are initiated by links on secure pages, but which refer
to insecure servers.

This restriction was implemented in N4.X to prevent session ids and other
similar information from being transmitted to the insecure site (over
unencrypted channels) in the Referer field.

Comment 1

[benc]

Makes sense to me. Is there any RFC that says this, just in case people complain
after we do this?

+qawanted, b/c someone should set up a test page to verify this when it gets done.

Comment 2

[Jeffrey Baker]

I made a testcase here: https://atari.saturn5.com/~jwb/referer-test.html Mozilla
2001-05-28-08 Linux trunk fails the test.

Comment 3

[Jeffrey Baker]

Of course you can also verify this using a network packet analyzer like ethereal
or tcpdump.

Comment 4

[Jeffrey Baker]

I added a second test which Mozilla also fails.  Is there a client security keyword?

Comment 5

[benc]

Bob:

Anything need to be done to this bug to make sure the right security people see it?

Comment 6

[Jeffrey Baker]

I hope nobody minds that I am reassigning this to security: crypto.

Comment 7

[Bob Lord]

Moving from Browser/Security:Crypto to PSM 2.0.

Comment 8

[Bob Lord]

p1

Comment 9

[Stephane Saux]

Attachment: Part of log of http server showing https referrer get data.

Comment 10

[Stephane Saux]

internal test case:
http://beaver.netscape.com
add something to the cart.
from the cart display, click on one of the navigation tabs, which use http://
The browser will send the https: referrer with all the data from the get that
produced the cart display.

Comment 11

[Stephane Saux]

PDT for PSM

Comment 12

[Stephane Saux]

PDT+ as per Steve Elmeer 6/20/2001

Comment 13

[selmer (gone)]

Adding dougt to the CC list, I believe he is helping with this one?  Any eta?

Comment 14

[David P. Drinan]

Re-assiging to Javi.

Comment 15

[Javier Delgadillo]

Attachment: patch that doesn't set referrer if it's an https field.

Comment 16

[Darin Fisher]

r/sr=darin

Comment 17

[chris hofmann]

a=chofmann

Comment 18

[Javier Delgadillo]

Patch checked in.

Comment 19

[Stephane Saux]

whiteboard: checked in; needs verification.

Comment 20

[John Unruh]

Marking verified. The 6/22 build passes Jaffrey Baker's test 
https://atari.saturn5.com/~jwb/referer-test.html

Comment 21

[Stephane Saux]

whiteboard->needs verification

Comment 22

[Mark Wagner]

The fix goes to far: now, 'Referer:' is stripped for all urls with https
schemes, even when retieving another secure page from the same server. For
example if you go to <https://www.lanfear.net/~mark/> and activate the "foo.pl"
link which goes to <https://www.lanfear.net/~mark/foo.pl> HTTP_REFERER is no
longer set. Both Netscape Communicator 4.76 and Mozilla 0.9.1 send the
'Referer:' header in this case.

It seems as though 'Referer:' should at least be present when retrieving another
secure document on the same server. My non-expert opinion is that 'Referer'
should always be present. It is the burden of the authors of the page to not put
links on their secure pages to unsecure documents when sensitive information is
part of the url. Either make the information part of a POST rather than a GET
(which makes bookmarking the page impossible, so this option isn't optimal), use
cookies to set and get the sensitive information, or simply have the links on
the page that would expose sensitive information point to a bouncer URL that
strips that info off before redirecting.

Thus, I suggest that this change be removed, or change Mozilla so that going
from secure document to secure document on the same host keeps the 'Referer:'
intact. (The latter would fix the problem I am having.) Looking at the patch
attached to this bug that seems as though the latter option would require major
work since it looks like 'Referer:' is turned on an off on a per-scheme basis
only with no finer grain of control.

Comment 23

[benc]

Mark:

I think your point makes good sense, are there sites that depend on this or
standards that reference this situation?

I'm not programmer, but wouldn't the proper methodology be to simply someone
check to see if the referer URL starts w/ "https://" and then set it to NULL? It
sounds like we should have a null check for sending "Refer: <NULL>" to remove
the line, so that would clean things up on the fly.

Comment 24

[Stephane Saux]

There are many reasons why web page designers want to refer to unsecure servers
from a secure page.
1) because https is more expensive, e-commerce site only use https for sensitive
operations. The resulting page will have links back to non-sensitive area of the
site such as browsing the catalog, and the link will have http:// hardcoded to
maximize the use of a cheaper resource.
2) because many site sign contract for advertising requiring that an http://
link be present on the result of a GET form submission using their own https
server.  It's presumptuous to ask them to jump through hoops to ensure that the
form submission data not be passed to their partner.

Nevertheless there is no reason to not include the referrer when the link is to
the same encrypted server.

Moreover, an argument can be made that even when the target is not using
encryption, then some part of the referrer should be available (maybe everything
before a "?").  Surely, much less sensitive information is encoded into the part
before the "?" than in the GET name/value pairs.

Comment 25

[Jeffrey Baker]

Whoa there :)  Don't make too many assumptions.  Many sites use a critical
session ID in the URL, not in the query string or cookies.  Commonly, these look
like https://somesite.com/deadbeef/path?query, or
https://somesite.com/path/deadbeef?query.  The existing behavior is the most
desirable from the site operator's standpoint: no referer header should ever be
sent from an https site to an http site, even if the the hostname is the same. 
Also of course it is very desirable to have referer headers within a secure
site, so this fix is broken.

Comment 26

[Stephane Saux]

ok, the argument can be made, but it's lousy.  I agree that the best
implementation should be as the previous poster.
Note that on 4.7X https => http on the same server sends the referrer. So this
would be more restrictive (and more secure).

I'm opening a new bug (this one is fixed, we don't send referrer to http).

Comment 27

[Stephane Saux]

Opened bug 89995