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.
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. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
