[whatwg] no referrer attribute for <a>, same reason as ping

On 1/18/06, Jasper Bryant-Greene <jasper at album.co.nz> wrote:
> On Wed, 2006-01-18 at 14:02 -0800, Tyler Close wrote:
> > I wrote:
> > > It would be nice to be able to directly specify the referer behaviour
> > > on the <a> element, instead of resorting to the same trickery
> > > currently used for click tracking.
> >
> > Here's a concrete proposal for what this could be:
>
> I quite like this proposal,

Thanks.

> but while we're at this early stage, it
> might be nice to correct the spelling to "referrer" on the attribute...
> fix a mistake made long ago by the HTTP guys...

Ok. I've also swapped around the 'r's in the email subject line to match. ;)

I think it is especially important that a feature like this one be
supported, since I think the current spec intends to drop support for
http-equiv META tags; one of the very few methods of controlling the
HTTP Referer header. Without the ability to control the HTTP Referer
header, it is just not safe to directly link from a private resource
to an external resource. Knowledge of the URL for a private resource
is often sufficient to mount a cross-site authorization attack.

For example, consider a resource at my bank which will perform a spend
when sent a POST with the expected HTTP Auth credentials, or session
cookie. This resource may be located at <https://bank/account/pay>.
Imagine I log into my bank account, check on some pending transactions
and then go visit some interesting blogs. At the end of a blog post is
a form submission button that claims to create a blog post comment.
The form actually points to <https://bank/account/pay> and does a
spend when I click on it. I click on the button, and my browser does
the form POST, happily responding to the bank's HTTP Auth challenge
using it's cached copy of my password. The spend goes through as it
was sent from my machine, using my password.

An easy way to guard against this kind of attack is to make the URL
for the private resource, <https://bank/account/pay> in the above
example, an unguessable URL, like
<https://bank/account/?key=1234-5678-9012>. Now, the blog post form in
the above example is unable to create an HTML form that points to the
bank spend resource. To keep this URL unguessable, it is important
that the browser not leak it through a Referer header. We need some
way for the HTTP server to tell the browser that the current resource
is private and must not be leaked.

More generally, you may just not want the target resource to know
where the link came from. For example, in an email conversation
discussion a web page, the participants may not want to reveal to the
web site operator that the content is being discussed in email. But if
the participants are using a webmail interface, clicking on the
discussed link reveals the existence of the conversation. The webmail
application should be able to present links that wont reveal their
existence to the link target.

A feature like this one is crucial if you are developing a web
application that involves private resources. As more applications move
from the desktop to the web browser, this feature becomes increasingly
important.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957

Received on Wednesday, 25 January 2006 14:12:39 UTC