Framed & Linked Content
Mike Potter
someone else has your page in a frame of theirs.
Is it possible to do this with PHP or is that the wrong side of
Server/Client-side operations?
Related, when target files are PDF's, images, or other than
.php/.htm(l), does PHP provide any remedies against that
sort of remote site linking?
Mike
Per Jessen
> There is JavaScript out there, to make a page break out of frames if
> someone else has your page in a frame of theirs.
> Is it possible to do this with PHP or is that the wrong side of
> Server/Client-side operations?
I haven't checked, but I'm wondering if the REFERER field might help you
if want to do a server-side redirect.
> Related, when target files are PDF's, images, or other than
> .php/.htm(l), does PHP provide any remedies against that
> sort of remote site linking?
Check the REFERER field.
/Per Jessen, Zürich
Robert Cummings
On Tue, 2008-01-29 at 10:21 -0500, Mike Potter wrote:
> There is JavaScript out there, to make a page break out of frames if
> someone else has your page in a frame of theirs.
> Is it possible to do this with PHP or is that the wrong side of
> Server/Client-side operations?
PHP can echo the JavaScript that facilitates the break out.
>
> Related, when target files are PDF's, images, or other than
> .php/.htm(l), does PHP provide any remedies against that
> sort of remote site linking?
The only remedy agaonst remote linking is to embed some kind of
expiration in the link that accesses the document. I usually do this by
using a combination of the document ID, a timestamp, and salt, and md5
or sha1. For instance the following:
<?php
$id = 'THE DOCUMENT ID :)';
$now = time();
$salt = 'Some site specific salt.';
$accessId = $id.':'.$now.':'.sha1( $id.':'.$now.':'.$salt );
echo '<a href="/docs/myDocument.php?id='.urlencode( $accessId ).'">'
.'The Document'
.'</a>';
?>
Then when someone actually requests the page we do the following:
<?php
$salt = 'Some site specific salt.';
$lifespan = 2 * 24 * 60 * 60; // 2 days
if( !($accessId = isset( $_GET['id'] ) ? $_GET['id'] : false) )
{
die( 'No document requested.' );
}
list( $id, $timestamp, $code ) = explode( ':', $accessId );
if( $code !== sha1( $id.':'.$timestamp.':'.$salt ) )
{
die( 'Invalid document request.' );
}
if( (time() - $lifespan) > $timestamp )
{
die( 'Document has expired.' );
}
// Otherwise flush document to browser.
?>
Now this doesn't stop anyone from saving the document locally but it
does prevent linking to your site and wasting your resources. The key to
the method is that only you know the $salt and so only you can create
the encoding that validates the passed ID and timestamp. You can also
add more attributes to the encoding such as a user ID. Then you could
ensure the user is logged in, and that the access ID must match their
logged in ID.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Robert Cummings
On Tue, 2008-01-29 at 11:12 -0500, Jason Pruim wrote:
> hopefully, I can learn from it! Wouldn't it be just as effective to
> have a salt that gets passed to the script and do something like:
>
> if($salt ="Correct salt"){
> //display correct picture
> }else{
> //display some random picture of a guy flipping you the bird and echo
> out Don't steal my pictures
> }
>
> Now that I type that out, I see that it will still use bandwidth which
> if you are on a measured plan I could see being a problem.
>
> So I think I just convinced my self that yours is better... Any thing
> really wrong with my idea though?
You can't pass the salt, the salt is like a password. If the end user
knows it they could arbitrarily change the document ID or timestamp in
which case access is no longer under your control. This is why we create
a sha1 encoding based on the document ID, the timestamp, and the salt.
If any of the parameters changes we don't get the access code and so we
know that tampering has occurred with the request parameters.
Jason Pruim
On Jan 29, 2008, at 10:58 AM, Robert Cummings wrote:
I'm probably about to show my ignorance here... But by showing it
hopefully, I can learn from it! Wouldn't it be just as effective to
have a salt that gets passed to the script and do something like:
if($salt ="Correct salt"){
//display correct picture
}else{
//display some random picture of a guy flipping you the bird and echo
out Don't steal my pictures
}
Now that I type that out, I see that it will still use bandwidth which
if you are on a measured plan I could see being a problem.
So I think I just convinced my self that yours is better... Any thing
really wrong with my idea though?
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
jap...@raoset.com
Per Jessen
> The only remedy agaonst remote linking is to embed some kind of
> expiration in the link that accesses the document.
Wouldn't a check of the REFERER field be enough to disable most remote
links? (I know it is easily forged.)
/Per Jessen, Zürich
Robert Cummings
Referer value is completely worthless. Many people completely disable
it-- such as myself :)
Per Jessen
>
> On Tue, 2008-01-29 at 17:32 +0100, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>> > The only remedy agaonst remote linking is to embed some kind of
>> > expiration in the link that accesses the document.
>>
>> Wouldn't a check of the REFERER field be enough to disable most
>> remote
>> links? (I know it is easily forged.)
>
> Referer value is completely worthless. Many people completely disable
> it-- such as myself :)
Well then - for people who've disabled it, there's no remote linking to
your content. All done.
/Per Jessen, Zürich
Per Jessen
> Referer value is completely worthless. Many people completely disable
> it-- such as myself :)
But most people probably don't - 'coz most don't know how to edit e.g.
the firefox config.
What is the purpose of disabling it?
/Per Jessen, Zürich
Per Jessen
> Well then - for people who've disabled it, there's no remote linking
> to your content. All done.
Btw, apache does a good job of dealing with remote links:
RewriteCond %{HTTP_REFERER} !^https?://jessen.ch/
RewriteRule /images/(.*) http://jessen.ch/no-remote-linking-please?item=$1
It's a rough example, but the idea should be obvious.
/Per Jessen, Zürich
Robert Cummings
On Tue, 2008-01-29 at 17:55 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > Referer value is completely worthless. Many people completely disable
> > it-- such as myself :)
>
> But most people probably don't - 'coz most don't know how to edit e.g.
> the firefox config.
I use Opera :)
> What is the purpose of disabling it?
Sites use it to cross reference your habits. It let's them know from
whence you've come. Whether that be google, msn, freepr0n, etc. No one's
business but my own how I arrived at point X in my surfing travels.
Robert Cummings
On Tue, 2008-01-29 at 17:50 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> >
> > On Tue, 2008-01-29 at 17:32 +0100, Per Jessen wrote:
> >> Robert Cummings wrote:
> >>
> >> > The only remedy agaonst remote linking is to embed some kind of
> >> > expiration in the link that accesses the document.
> >>
> >> Wouldn't a check of the REFERER field be enough to disable most
> >> remote
> >> links? (I know it is easily forged.)
> >
> > Referer value is completely worthless. Many people completely disable
> > it-- such as myself :)
>
> Well then - for people who've disabled it, there's no remote linking to
> your content. All done.
Is that what you tell paid subscribers? I'd tell you where to shove
it :)
Robert Cummings
On Tue, 2008-01-29 at 13:01 -0500, Robert Cummings wrote:
> On Tue, 2008-01-29 at 17:55 +0100, Per Jessen wrote:
> > Robert Cummings wrote:
> >
> > > Referer value is completely worthless. Many people completely disable
> > > it-- such as myself :)
> >
> > But most people probably don't - 'coz most don't know how to edit e.g.
> > the firefox config.
>
> I use Opera :)
>
> > What is the purpose of disabling it?
>
> Sites use it to cross reference your habits. It let's them know from
> whence you've come. Whether that be google, msn, freepr0n, etc. No one's
> business but my own how I arrived at point X in my surfing travels.
Actually, now you made me think on it... the primary reason I disable
referrer logging is because it will also pass along lovely information
such as any session ID embedded in the URL. So if you happen to get on a
malicious site, they could access the account from which you've come.
Per Jessen
> Actually, now you made me think on it... the primary reason I disable
> referrer logging is because it will also pass along lovely information
> such as any session ID embedded in the URL. So if you happen to get on
> a malicious site, they could access the account from which you've
> come.
Hmm, interesting idea. I wonder if the sessionid isn't tied to the
IP-address even when it's part of the URL?
Still, I can't help thinking that if this is a serious problem, it would
have been dealt with long ago.
/Per Jessen, Zürich
Robert Cummings
On Tue, 2008-01-29 at 19:48 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > Actually, now you made me think on it... the primary reason I disable
> > referrer logging is because it will also pass along lovely information
> > such as any session ID embedded in the URL. So if you happen to get on
> > a malicious site, they could access the account from which you've
> > come.
>
> Hmm, interesting idea. I wonder if the sessionid isn't tied to the
> IP-address even when it's part of the URL?
It sure isn't. AOL is known to on the fly change your connection domain
so tying an IP address to a session ID won't work very well for people
connecting via AOL. Similar problems exist for multiple users behind
NAT. Other companies do similar. You can test for yourself too... the
default session ID created via PHP sessions is not tied to anything.
> Still, I can't help thinking that if this is a serious problem, it would
> have been dealt with long ago.
http://www.google.com/search?hl=en&q=referer+session+hijacking
Richard Lynch
> There is JavaScript out there, to make a page break out of frames if
> someone else has your page in a frame of theirs.
> Is it possible to do this with PHP or is that the wrong side of
> Server/Client-side operations?
PHP is the wrong side of the tracks for that.
> Related, when target files are PDF's, images, or other than
> .php/.htm(l), does PHP provide any remedies against that
> sort of remote site linking?
Not really.
You can require a login or other authentication by using a PHP wrapper
that spews out the PDF/image/whatever.
But an HTTP request is an HTTP request which your server will respond
to unless you add logic in PHP to make it respond differently.
Nothing built-in; Just plenty of tools to build whatever you want.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
Richard Lynch
Normal users also use browsers which choose not to send it all.
If you don't mind losing X% of your audience because they like to use
such a browser, you're all set... :-v
Richard Lynch
It's none of your [bleep] business what website I was on before I came
to your site...
Large companies and advertising and the sharing of personal data in
the background makes this a pretty serious privacy issue if you think
about it for a while.
Richard Lynch
> Robert Cummings wrote:
>
>> Actually, now you made me think on it... the primary reason I
>> disable
>> referrer logging is because it will also pass along lovely
>> information
>> such as any session ID embedded in the URL. So if you happen to get
>> on
>> a malicious site, they could access the account from which you've
>> come.
>
> Hmm, interesting idea. I wonder if the sessionid isn't tied to the
> IP-address even when it's part of the URL?
It CANNOT be tied to the IP address, because most users' IP addresses
are not static.
Google for "session hijacking" for more info.
> Still, I can't help thinking that if this is a serious problem, it
> would
> have been dealt with long ago.
War is a serious problem.
So is murder.
So is people cutting me off in traffic. :-v
None of them have been dealt with effectively yet.
Per Jessen
> On Tue, January 29, 2008 10:32 am, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>>> The only remedy agaonst remote linking is to embed some kind of
>>> expiration in the link that accesses the document.
>>
>> Wouldn't a check of the REFERER field be enough to disable most
>> remote links? (I know it is easily forged.)
>
> Normal users also use browsers which choose not to send it all.
>
> If you don't mind losing X% of your audience because they like to use
> such a browser, you're all set... :-v
I think it's more likely to be 0.00X% ... and I dont personally mind
that. :-)
/Per Jessen, Zürich
Per Jessen
> On Tue, January 29, 2008 12:48 pm, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>>> Actually, now you made me think on it... the primary reason I
>>> disable
>>> referrer logging is because it will also pass along lovely
>>> information
>>> such as any session ID embedded in the URL. So if you happen to get
>>> on
>>> a malicious site, they could access the account from which you've
>>> come.
>>
>> Hmm, interesting idea. I wonder if the sessionid isn't tied to the
>> IP-address even when it's part of the URL?
>
> It CANNOT be tied to the IP address, because most users' IP addresses
> are not static.
I think it is for the duration of the session. Mine certainly is.
> Google for "session hijacking" for more info.
>
>> Still, I can't help thinking that if this is a serious problem, it
>> would have been dealt with long ago.
>
> War is a serious problem.
>
> So is murder.
>
> So is people cutting me off in traffic. :-v
>
> None of them have been dealt with effectively yet.
Sure it has - nobody cuts me off in traffic here. :-)
Regardless, I did some googling and read a bit about session hijacking
and such. I still don't see much of a serious problem. When Firefox
switches off REFERER by default, we can talk again.
/Per Jessen, Zürich
Richard Lynch
> Richard Lynch wrote:
>
>> On Tue, January 29, 2008 12:48 pm, Per Jessen wrote:
>>> Robert Cummings wrote:
>>>
>>>> Actually, now you made me think on it... the primary reason I
>>>> disable
>>>> referrer logging is because it will also pass along lovely
>>>> information
>>>> such as any session ID embedded in the URL. So if you happen to
>>>> get
>>>> on
>>>> a malicious site, they could access the account from which you've
>>>> come.
>>>
>>> Hmm, interesting idea. I wonder if the sessionid isn't tied to the
>>> IP-address even when it's part of the URL?
>>
>> It CANNOT be tied to the IP address, because most users' IP
>> addresses
>> are not static.
>
> I think it is for the duration of the session. Mine certainly is.
Yours might be.
AOL users are *NOT*.
In peak periods, an AOL users' IP address with change with every HTTP
request.
Further, large corporate users will ALL appear as a single IP address.
>> Google for "session hijacking" for more info.
>>
>>> Still, I can't help thinking that if this is a serious problem, it
>>> would have been dealt with long ago.
>>
>> War is a serious problem.
>>
>> So is murder.
>>
>> So is people cutting me off in traffic. :-v
>>
>> None of them have been dealt with effectively yet.
>
> Sure it has - nobody cuts me off in traffic here. :-)
>
> Regardless, I did some googling and read a bit about session hijacking
> and such. I still don't see much of a serious problem. When Firefox
> switches off REFERER by default, we can talk again.
Suppose only 0.1% of the Internet users have REFERER off.
You say "That's not much. 0.1%"
Now suppose there are a billion people who use the Internet.
What is 0.1% of a billion?
Do the math.
If you have even a few thousand visitors, you are likely getting at
least a few that have no REFERER...
Eric Butera
>
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
The fact it can be tampered with should be enough to ignore it, right?
Per Jessen
>>> It CANNOT be tied to the IP address, because most users' IP
>>> addresses are not static.
>>
>> I think it is for the duration of the session. Mine certainly is.
>
> Yours might be.
> AOL users are *NOT*.
> In peak periods, an AOL users' IP address with change with every HTTP
> request.
Surely you are joking?? Don't they use DHCP for dishing out addresses?
I guess AOL users just have to do without https during peak hours :-)
> Further, large corporate users will ALL appear as a single IP address.
Yes, that's assuming they're using NAT - which many small and large
entities will be, I agree. In such cases, if the session id _is_
somehow tied to the IP-address, any attempt to hijack the session from
outside the NAT'ed network will fail.
>> Regardless, I did some googling and read a bit about session
>> hijacking and such. I still don't see much of a serious problem.
>> When Firefox switches off REFERER by default, we can talk again.
>
> Suppose only 0.1% of the Internet users have REFERER off.
>
> You say "That's not much. 0.1%"
>
> Now suppose there are a billion people who use the Internet.
>
> What is 0.1% of a billion?
>
> Do the math.
10million. But what I said was that _maybe_ 0.00X% have REFERER
switched off - and 0.001% of 1billion is 10.000 people. I can live
with that.
> If you have even a few thousand visitors, you are likely getting at
> least a few that have no REFERER...
Like I said, I can live with that. If people are that paranoid, they
shouldn't be on the internet at all, IMHO.
/Per Jessen, Zürich
Per Jessen
>
> The fact it can be tampered with should be enough to ignore it, right?
>
Well, no. _anything_ can be tampered with given the right amount of
resources. For instance, exactly _when_ an otherwise unbreakable
encryption is borken is _only_ a matter of money. How far you go in
securing content (or whatever) is purely a matter of how far someone
will go in an attempt to overcome your security.
To get back on topic, if you're insanely paranoid about people getting
access to your content by direct remote links, of course you can't rely
on REFERER and you'll have to use a more complex scheme.
Otherwise, when you do rely on REFERER, 1) you will be shutting out
other insanely paranoid people who do not provide a REFERER and 2) you
leave your content available to individuals who forge the REFERER.
Personally I think 1) is good and 2) is acceptable.
/Per Jessen, Zürich
Robert Cummings
Not just people. Many firewalls either strip or modify the referrer.
Information leakage is a security issue. IMHO referer logging should
need to be turned on, not off.
Per Jessen
> Information leakage is a security issue. IMHO referer logging should
> need to be turned on, not off.
Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
switches off REFERER by default, we can talk again.
/Per Jessen, Zürich
Andrew Ballard
> Richard Lynch wrote:
>
> >>> It CANNOT be tied to the IP address, because most users' IP
> >>> addresses are not static.
> >>
> >> I think it is for the duration of the session. Mine certainly is.
> >
> > Yours might be.
> > AOL users are *NOT*.
> > In peak periods, an AOL users' IP address with change with every HTTP
> > request.
>
> Surely you are joking?? Don't they use DHCP for dishing out addresses?
> I guess AOL users just have to do without https during peak hours :-)
No, that's not it. The AOL users do have a consistent IP to connect to
the AOL network during a given session. However, AOL routes their
traffic through proxy servers and you may or may not get the same
proxy with each request. It does seem to be more consistent than it
used to, but to the web server, it is very possible that each request
will come from a different IP. And I don't believe AOL uses the
X-Apparently-For (or whatever that header is) either.
> Like I said, I can live with that. If people are that paranoid, they
> shouldn't be on the internet at all, IMHO.
It's not just paranoia over having sessions hijacked. You could still
have sensitive data leaked from query string params that have nothing
to do with the session information, not to mention some people just
don't like telling every web site where they came from. There doesn't
have to be anything nefarious.
Personally, I haven't munged with my referer any, but I do think it
should be easier for users to choose whether it should be sent
regardless of which browser they are using.
Andrew
Robert Cummings
Lol, this is an open discussion. I post for all to read, not just you.
Andrew Ballard
It's been a long time, but I seem to recall there was a version of
either Netscape or IE (pretty mainstream) around v4 that did not send
it. I was setting up one of those wonderful little formmail scripts
that used REFERER to determine whether you were allowed to submit to
the form, and was bugged at why I kept getting messages saying I
wasn't authorized when I know I came from an "authorized" page. Turns
out, the value of REFERER was blank.
Andrew
Robert Cummings
On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
> > Robert Cummings wrote:
> >
> > > Information leakage is a security issue. IMHO referer logging should
> > > need to be turned on, not off.
> >
> > Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
> > switches off REFERER by default, we can talk again.
>
> Lol, this is an open discussion. I post for all to read, not just you.
FWIW BTW, they will probably never switch it off for the same reason
Windows isn't locked down properly by default. Too many dumb users would
cry WTF and wouldn't understand the answer. As such the simplest
solution is to leave users exposed rather than educating them.
Per Jessen
>>> Yours might be.
>>> AOL users are *NOT*.
>>> In peak periods, an AOL users' IP address with change with every
>>> HTTP request.
>>
>> Surely you are joking?? Don't they use DHCP for dishing out
>> addresses? I guess AOL users just have to do without https during
>> peak hours :-)
>
> No, that's not it. The AOL users do have a consistent IP to connect to
> the AOL network during a given session. However, AOL routes their
> traffic through proxy servers and you may or may not get the same
> proxy with each request. It does seem to be more consistent than it
> used to, but to the web server, it is very possible that each request
> will come from a different IP. And I don't believe AOL uses the
> X-Apparently-For (or whatever that header is) either.
There is some or other header that is intended for making the target
server aware of proxying, but I can't remember what it is either.
>> Like I said, I can live with that. If people are that paranoid, they
>> shouldn't be on the internet at all, IMHO.
>
> It's not just paranoia over having sessions hijacked. You could still
> have sensitive data leaked from query string params that have nothing
> to do with the session information, not to mention some people just
> don't like telling every web site where they came from. There doesn't
> have to be anything nefarious.
Oh, I agree with that. To me it just still comes under the paranoia
heading. Wrt to "people just don't like telling every web site where
they came from", that's also a fair point. Then it's up to me as a
developer to determine if I can be bothered to cater to those too.
Especially when it only takes 2-3 lines of apache config to deal with
the 99.999% of my (less paranoid) users.
> Personally, I haven't munged with my referer any, but I do think it
> should be easier for users to choose whether it should be sent
> regardless of which browser they are using.
I think that's a fair request - how about an option for "omit REFERER
when changing websites only" ? Now, where's that Firefox wishlist?
/Per Jessen, Zürich
Per Jessen
> On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
>> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
>> > Robert Cummings wrote:
>> >
>> > > Information leakage is a security issue. IMHO referer logging
>> > > should need to be turned on, not off.
>> >
>> > Rob, I appreciate your opinion, but like I said - when Firefox (or
>> > MSIE) switches off REFERER by default, we can talk again.
>>
>> Lol, this is an open discussion. I post for all to read, not just
>> you.
>
> FWIW BTW, they will probably never switch it off for the same reason
> Windows isn't locked down properly by default. Too many dumb users
> would cry WTF and wouldn't understand the answer. As such the simplest
> solution is to leave users exposed rather than educating them.
I'm certain they'll never switch it off by default. Well, at least not
until we have a new HTTP spec that specifically deprecates REFERER.
I won't hold my breath :-)
/Per Jessen, Zürich
Robert Cummings
On Thu, 2008-01-31 at 21:32 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
> >> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
> >> > Robert Cummings wrote:
> >> >
> >> > > Information leakage is a security issue. IMHO referer logging
> >> > > should need to be turned on, not off.
> >> >
> >> > Rob, I appreciate your opinion, but like I said - when Firefox (or
> >> > MSIE) switches off REFERER by default, we can talk again.
> >>
> >> Lol, this is an open discussion. I post for all to read, not just
> >> you.
> >
> > FWIW BTW, they will probably never switch it off for the same reason
> > Windows isn't locked down properly by default. Too many dumb users
> > would cry WTF and wouldn't understand the answer. As such the simplest
> > solution is to leave users exposed rather than educating them.
>
> I'm certain they'll never switch it off by default. Well, at least not
> until we have a new HTTP spec that specifically deprecates REFERER.
> I won't hold my breath :-)
Interesting you mention the HTTP spec...
14.36 Referer
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. See
section 15.1.3 for security considerations.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15.1.3 Encoding Sensitive Information in URI's
Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From
information.
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
Authors of services which use the HTTP protocol SHOULD NOT use GET
based forms for the submission of sensitive data, because this will
cause this data to be encoded in the Request-URI. Many existing
servers, proxies, and user agents will log the request URI in some
place where it might be visible to third parties. Servers can use
POST-based form submission instead
So at least the spec explicitly recommends allowing the user to set
whether the referrer is sent. As such, no site should rely on it.
Per Jessen
> So at least the spec explicitly recommends allowing the user to set
> whether the referrer is sent. As such, no site should rely on it.
Agreed, in principle it should not be relied upon. But then neither
should MSIE[567] :-)
Besides, today Firefox and Opera both allow the user to set whether the
referrer is sent.
Until the default is changed to not to send it, I'll stick to using
REFERER. If/when the time comes, it's an easy change, and until then
it's no headache.
Anyway, thanks for some interesting points, Rob - I like an intelligent
response. Quoting the HTTP spec to me was good - I'll have to be a
little wary of you in the future :-)
/Per Jessen, Zürich
Robert Cummings
> Robert Cummings wrote:
>
> response. Quoting the HTTP spec to me was good - I'll have to be a
> little wary of you in the future :-)
I was just padding my end of week bytecount ;)