HTTP_REFERER from https: not sent to FRAME SRC

VERIFIED WORKSFORME

Status

()

Core
Networking: HTTP
P3
normal
VERIFIED WORKSFORME
18 years ago
15 years ago

People

(Reporter: Alexander LeDonne, Assigned: Gagan)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
Nightly Build ID 2000040616

URL above will return a form.
Clicking the button will return test.cgi with an HTTP_REFERER, which produces a
frameset with sources test.cgi?frame1=frame1 and test.cgi?frame2=frame2

The frames should then be blue, as the script should get an HTTP_REFERER and a
QUERY_STRING (test in Netscape Communicator 4.x - although Communicator sends
the REFERER of the frameset doc as the REFERER of the individual frames; it
should send the URI of the FRAMESET doc as the REFERER of the frames).

However, the frame sources do not get the HTTP_REFERER header - even though the
frameset doc (test.cgi) should be listed as the REFERER.

I will be happy to modify test.cgi upon request, or to furnish the code (perl).
aledonne@iupui.edu - frames are now blue. If this is still a problem, ask for 
this bug to be reopened. Marking WORKSFORME :-)

Gerv
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

18 years ago
Confirming resolved. Thanks.

Comment 3

18 years ago
No longer there. Marking as verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 4

16 years ago
This is back; I've replaced the old URL with one more current.

The frames no longer turn blue when correct. Seemed silly. I've added a 
JavaScript alert in the parent frameset - oddly enough, the parent frameset 
gets the HTTP_REFERER, but the individual frames don't.

The individual frames do get it using Netscape Navigator 4.7x, they don't using 
Netscape 6.x.

There is possibly a server-side component at work here as well, but we couldn't 
find anything in our apache httpd.conf that would cause different behavior for 
Netscape Navigator 4.7x and Mozilla.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Alexander, that url requires a password to access...  How can I test this bug?
See testcase at 
http://www.zbarsky.org:8000/~bzbarsky/testcases/networking/frame_referer.html  
That simply loads a script in a frame.  That script echoes whatever Referer 
header it got.

Resolving worksforme once again, since it does on that testcase.  Please make 
sure your page is not loading insecure pages in the frames or pages from other 
servers.  In those cases we do not send a Referer header (from an https page) 
for security reasons.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 7

16 years ago
Egad. So this is a "security feature"? I don't entirely get it, but oh well. 
We'll have to abandon Mozilla/Netscape 6.x support until we get a new system. 
While we know the Referer: header is easily spoofed, referer checking has always 
been handy to keep out the casual snooper. And yes, our application does require 
pages from multiple servers in https framesets.

Thanks for the explanation.
You may want to see bug 141641.  That's where the discussion is going on about 
maybe changing this to sort of work with systems like yours while still not 
disclosing user information which may be encoded in the URL.

Updated

16 years ago
QA Contact: tever → benc

Updated

16 years ago
Component: Networking → Networking: HTTP
QA Contact: benc → tever

Comment 9

15 years ago
VERIFIED:
This is the desired behavior.

Alexander, if you are still out there, I'd be interested in getting he code
snipped you use to turn things blue, I'm trying to standardize some testcases
and publish them on mozilla.org.
Status: RESOLVED → VERIFIED
Summary: HTTP_REFERER not sent to FRAME SRC → HTTP_REFERER from https: not sent to FRAME SRC
You need to log in before you can comment on or make changes to this bug.