#127 assigned defect

Cap URLs leaked via HTTP Referer header

Reported by: warner Owned by: davidsarah
Priority: major Milestone: soon
Component: code-frontend-web Version: 0.7.0
Keywords: confidentiality integrity preservation capleak research websec Cc:
Launchpad Bug:

Description (last modified by warner)

It occurred to me that, despite the show-all-files-by-URI change we made to protect the private-vdrive URI from referrer headers and active javascript attacks, that there is still one remaining: the URI of the HTML file itself.

Let's say that you write a secret HTML document and upload it to the grid, attached to some directory in your private vdrive so nobody else can see it. In this document you include an HREF to mysuperevilsite.org, because it's really cool. When you use your tahoe node's web server to read that document, it will serve it to you as /uri/RANDOMURI, and when you follow that HREF to the super evil site, I (as the operator ot mysuperevilsite.org) will see a Referrer header with /uri/RANDOMURI in it. Then I fire up my own tahoe node and get to read your secret document.

Alternatively, once you're viewing a page from the evil site, I can put javascript in that page which uses your tahoe node to read /uri/RANDOMURI and do something clever to get the data back to me.

I'm less concerned about this one than the previous attack (#98), but it would still be nice to find a way to fix it. I can't think of any clever solutions, though. Note that the javascript attack means that (like with all confused deputy attacks) somehow encrypting the URL wouldn't help (since ambient authority can still be exploited by the attacker).

Attachments (1)

restrict-referrer-leakage.txt (4.9 KB) - added by davidsarah at 2012-09-13T03:41:40Z.
Proposed Content-Security-Policy directive: "restrict-referrer-leakage"

Download all attachments as: .zip

Change History (46)

comment:2 Changed at 2007-09-25T04:32:43Z by zooko

  • Milestone changed from undecided to 0.6.1
  • Version changed from 0.5.1 to 0.6.0

I want to go over this carefully, and some related issues about navigation in the web user interface, for the v0.6.1 release in two weeks. See the aforementioned mailing list thread for starters.

comment:3 Changed at 2007-10-01T22:12:42Z by zooko

See also #103.

comment:4 Changed at 2007-10-13T06:35:25Z by zooko

  • Milestone changed from 0.6.1 to 0.7.0

Bumping this to v0.7.

comment:5 Changed at 2007-10-15T18:49:54Z by zooko

  • Summary changed from smaller XSRF attack still possible to smaller CSRF attack still possible

comment:6 Changed at 2007-11-01T19:43:04Z by zooko

  • Milestone changed from 0.7.0 to 0.7.1
  • Version changed from 0.6.0 to 0.6.1

We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

comment:7 Changed at 2007-11-13T18:35:47Z by zooko

  • Milestone changed from 0.7.1 to 1.0
  • Version changed from 0.6.1 to 0.7.0

It would be good to tighten our security properties here, but I don't think we are going to get it done in the next six weeks, so I'm putting it in Milestone 1.0.

comment:8 Changed at 2008-02-27T22:29:27Z by zooko

from IRC:

<kpreid_> http://allmydata.org/trac/tahoe/ticket/127 -- When I asked Tyler Close about this back at the Croquet workshop, he said that HTTPS drops the referrer header so that things like this don't arise.

<kpreid_> Another workaround is to rewrite links into a redirection service (your own, typically) so that the referrer is the redirector, not the private URL

<kpreid_> (but HTTPS is probably a better idea provided one can provide it)

<warner> #127: good to know, I didn't think HTTPS did that. I've kicked this around with Tyler a couple of times, I think his recommendation would be to use JS and the fragment header, but a) that would require JS, and b) I don't see how it could work with anything but HTML-for-display (not for downloading arbitrary files)

comment:9 follow-up: Changed at 2008-02-27T22:58:42Z by zooko

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36

and

http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3

Here are the parts that are potentially useful to us:

  • "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."
  • "The URI MUST NOT include a fragment."
  • "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."

comment:10 Changed at 2008-03-21T22:37:40Z by zooko

  • Milestone changed from 1.0 to undecided

comment:11 Changed at 2008-06-01T20:47:43Z by warner

  • Milestone changed from eventually to undecided

comment:12 Changed at 2009-10-28T06:25:20Z by davidsarah

  • Keywords security added
  • Priority changed from minor to major
  • Summary changed from smaller CSRF attack still possible to Cap URLs leaked via HTTP Referer header

This attack isn't CSRF; changing the summary accordingly.

If you like this bug, you might also like #615 and #821 :-)

(#821 is about leaking the URL to scripts in the file itself, #615 is about leaking it to other pages.)

comment:13 in reply to: ↑ 9 Changed at 2009-10-29T06:11:29Z by davidsarah

Replying to zooko:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3

  • "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

I have heard someone, I think Tyler Close, say that clients interpret this in a stupidly literal way: they do include the Referer header in an HTTP-over-SSL/TLS request -- because that is not a "non-secure" request -- when the referring page was also transferred over HTTP-over-SSL/TLS, even if the keys or domains are different.

Also, http://community.livejournal.com/lj_dev/707379.html seems to suggest that non-Mozilla browsers do not follow the above restriction on sending Referer at all -- although that was in 2006.

comment:14 Changed at 2009-10-29T06:34:50Z by davidsarah

The behaviour of Mozilla browsers for the secure -> secure case is controlled by this preference [note "rr" spelling]:

http://kb.mozillazine.org/Network.http.sendSecureXSiteReferrer

Summary: it does the wrong thing by default :-(

(This preference controls when to send Referer in other cases:

http://kb.mozillazine.org/Network.http.sendRefererHeader

I just changed my Firefox config to never send it, i.e. network.http.sendRefererHeader = 0 and network.http.sendSecureXSiteReferrer = false. I doubt anything will break.)

comment:15 Changed at 2009-10-29T06:44:55Z by davidsarah

Microsoft cannot be trusted to document IE's behaviour; their knowledge base article at

http://support.microsoft.com/kb/178066

is contradicted by

http://marc.info/?l=bugtraq&m=107282279713152&w=2

comment:16 Changed at 2009-10-29T16:11:25Z by zooko

Last year I asked Collin Jackson (who knows a good deal about web security) how to automatically prevent Referer Headers from being sent. He repied:

Most of the techniques involve making the request come from a non-HTTP scheme. The browser usually won't bother to send a Referer in this case.

Option A: ftp scheme

ftp://site.com/source.html

Option B: about:blank scheme

w = window.open("");
w.document.write("<form ...>");
w.document.forms[0].submit();

Option C: javascript: scheme

window.location="javascript:'<script>window.location='...</script>'"

comment:17 Changed at 2009-10-29T19:04:43Z by davidsarah

If all of these work, option C seems to be the simplest. Option A requires an ftp server, which seems like an unwarranted excursion if we can possibly avoid it. Option B depends on more of the DOM and HTML, hence greater exposure to browser idiosyncrasies, than option C does.

(The location URL in option C needs to be properly escaped for an URL-in-JSStringLiteral-in-HTML-in-JSStringLiteral-in-JSStringLiteral-in-HTML, but that's straightforward :-)

comment:18 Changed at 2009-10-29T19:33:17Z by zooko

  • Summary changed from Cap URLs leaked via HTTP Referer header to v

I don't really understand those options very well or how they would be implemented in Tahoe-LAFS. I should mention another option: moving the cap from the URL itself into the URL fragment, as Tyler Close's web-key does: http://waterken.sourceforge.net/web-key .

This would certainly prevent caps from leaking into the Referer header, although they might still leak due to tools like "Yahoo Toolbar" and the like. (Tools which send all the URLs that you view to some remote server for you.)

Also, as Brian wrote in comment:8, it isn't clear how Tahoe-LAFS could use caps-in-fragments for purposes other than displaying the result in on a web page. Perhaps there could be a two-layer design where the WAPI has caps in URLs (which is consistent with the REST paradigm), but a new WUI (which would be written in JavaScript, Cajita or Jacaranda) would somehow translate between caps-in-fragments and caps-in-URLs so that the URL that actually appeared in the URL widget would always be caps-in-fragment.

comment:19 Changed at 2009-10-29T19:37:53Z by zooko

  • Summary changed from v to Cap URLs leaked via HTTP Referer header

comment:20 follow-up: Changed at 2009-10-29T20:54:33Z by davidsarah

For anyone trying to test option C, the syntax above was wrong; it should be

<script>window.location="javascript:window.location='capURL'"</script>

However, I'm not sure that options B or C work for what we are trying to do. The problem we're trying to solve is that following a link from the contents of a Tahoe file may reveal the file's URL ('capURL'). Options B and C prevent the page at 'capURL' from seeing the referring URL (of the page containing the JavaScript), but they don't prevent leakage of 'capURL' to a site that the page at 'capURL' links to.

Only option A allows to you prevent sending a Referer header when following a link from a page with arbitrary contents (by serving that page via FTP).

comment:21 in reply to: ↑ 20 ; follow-up: Changed at 2009-10-29T21:40:45Z by davidsarah

Replying to davidsarah:

However, I'm not sure that options B or C work for what we are trying to do.

Actually there's a variant of B that will work: send the read cap in the form data. You would make an initial request to the gateway for a given read cap encoded in the URL, and would get back a stub page containing a form filled in with that read cap. If that form is POSTed to the gateway, it would respond with the real file. When POST is used, the URL of the latter would just be the URL of the form, which is not sensitive, so it doesn't matter whether it is leaked via Referer.

This approach needn't depend on JavaScript, but if you don't have JavaScript the user would have to click a button to submit the form. (Is there a way to do that automatically on page load even if scripting is disabled?) Alternatively the server could set a cookie and have that cookie echoed back to it with an HTTP-Refresh, but that potentially introduces other cookie-related weaknesses and complications.

In the case where the referring page is generated by the gateway (for example a directory listing), then that page can directly include a form for each file link, so there is no extra request or button click even when scripting is disabled.

If you can depend on JavaScript, you can combine this with Tyler's approach and put the sensitive part of the URL in the fragment, then have a script copy it to the form data. The difference is that because form submission is used instead of XMLHttpRequest, you can download arbitrary files rather than just displaying them.

A disadvantage of using POST is that if the user goes back to an URL via the history, they will get a spurious prompt asking whether they want to resubmit form data. (Using GET won't work, because then the read cap would still be in the URL.) I think this is acceptable, though.

comment:22 in reply to: ↑ 21 Changed at 2009-10-29T21:45:13Z by davidsarah

Replying to davidsarah:

... send the read cap in the form data ...

This approach would simultaneously fix #821. It would not fix #615.

comment:23 Changed at 2009-10-29T23:46:47Z by davidsarah

  • Summary changed from Cap URLs leaked via HTTP Referer header to Cap URLs leaked via HTTP Referer header, and to phishing filters

We don't appear to have a separate ticket about cap URLs leaking to phishing filters. Let's consider this ticket to cover both issues, since it is possible that the same solution could work. If we depend on JavaScript, I think that the fragment + form technique in comment:21 solves both.

comment:24 Changed at 2009-12-04T04:25:24Z by davidsarah

  • Keywords confidentiality integrity dataloss added; security removed

comment:25 Changed at 2009-12-13T03:28:26Z by davidsarah

  • Keywords preservation added; dataloss removed

comment:26 Changed at 2010-01-17T14:54:27Z by davidsarah

  • Keywords capleak added
  • Summary changed from Cap URLs leaked via HTTP Referer header, and to phishing filters to Cap URLs leaked via HTTP Referer header

I split the phishing filter problem into #907 (having forgotten that I'd covered it here, but it is a separate issue).

comment:27 Changed at 2010-04-12T20:23:52Z by davidsarah

  • Milestone changed from undecided to 1.8.0
  • Owner set to davidsarah
  • Status changed from new to assigned

I plan to fix this along the lines described in comment:21.

comment:28 Changed at 2010-08-09T22:17:03Z by zooko

  • Milestone changed from 1.8.0 to 1.9.0

comment:29 Changed at 2010-12-25T00:15:58Z by warner

Incidentally, someone told me the other day that any URLs sent through various google products (Google Talk the IM system, Gmail, anything you browse while the Google Toolbar is in your browser) gets spidered and added to the public index. The person couldn't think of any conventions (beyond robots.txt) to convince them to *not* follow those links, but they could think of lots of things to encourage their spider even more.

I plan to do some tests of this (or just ask google's spider to tell me about tests which somebody else has undoubtedly performed already).

I know, I know, it's one of those boiling the ocean things, it's really unfortunate that so many tools are so hostile to the really-convenient idea of secret URLs.

comment:30 Changed at 2011-05-28T19:27:13Z by davidsarah

  • Milestone changed from 1.9.0 to 1.10.0

comment:31 Changed at 2012-09-13T03:38:32Z by davidsarah

I wrote up a spec for a new Content-Security-Policy directive that would allow us (or any server operator) to completely block Referer leakage. I'll attach it here.

Version 0, edited at 2012-09-13T03:38:32Z by davidsarah (next)

Changed at 2012-09-13T03:41:40Z by davidsarah

Proposed Content-Security-Policy directive: "restrict-referrer-leakage"

comment:32 follow-ups: Changed at 2012-10-28T09:24:20Z by ChosenOne

The noreferrer attribute on links could prevent leaking dircaps when clicking the link to a potentially malicious html file on the WUI http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

comment:33 follow-up: Changed at 2012-10-28T16:35:39Z by zooko

I'd like to try to get the restrict-referrer-leakage CSP standardized and supported by user agents. What's the next step? Write to some W3C Web Sec working group, post david-sarah's attachment:restrict-referrer-leakage.txt, and ask them to consider it?

comment:34 in reply to: ↑ 32 Changed at 2012-10-28T16:36:37Z by zooko

Replying to ChosenOne:

The noreferrer attribute on links could prevent leaking dircaps when clicking the link to a potentially malicious html file on the WUI http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

Neat! Thank you! We could even consider (reluctant as I am to get into HTML rewriting) trying to inject that attribute onto arbitrary links inside HTML that the tahoe gateway serves up!

comment:35 in reply to: ↑ 32 Changed at 2012-10-29T17:49:50Z by davidsarah

Replying to ChosenOne:

The noreferrer attribute on links could prevent leaking dircaps when clicking the link to a potentially malicious html file on the WUI http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

restrict-referrer-leakage.txt is a more complete and simpler solution, as the spec says:

The effect of this directive with an empty set of allowed referrer recipients includes the effect of treating all links from the affected documents as having the _noreferrer link type_ [HTML5]. However, this directive:

  • applies to all requests, rather than only to requests made as a result of following links defined by an HTML 'a' or 'area' element;
  • does not require rewriting links to have the noreferrer type;
  • enables the set of allowed referrer recipients to be controlled, subject to any other user-agent-dependent restrictions as mentioned above;
  • is resistant to content injection attacks (at least in the case where the Content-Security-Policy is specified by HTTP header).

(We don't need the third point but the other three are important, because rewriting is hard.)

comment:36 in reply to: ↑ 33 Changed at 2012-10-29T17:50:45Z by davidsarah

Replying to zooko:

I'd like to try to get the restrict-referrer-leakage CSP standardized and supported by user agents. What's the next step? Write to some W3C Web Sec working group, post david-sarah's attachment:restrict-referrer-leakage.txt, and ask them to consider it?

Yes. I will do that some time in the next few days.

comment:37 Changed at 2012-12-05T20:24:29Z by zooko

Opened #1890 (submit proposal for restrict-referer-leakage to the CSP standardizers and implementors) for that part of this project.

comment:38 Changed at 2013-01-04T21:31:09Z by zooko

  • Keywords research added

comment:39 Changed at 2013-05-28T17:42:25Z by warner

  • Description modified (diff)

I just learned that there's an HTML meta tag specifically to control Referer leakage, and that it's already implemented in a couple of browsers (chrome now, FF in progress, but alas not IE):

The FF bugzilla discussion also mentions some per-link options.

comment:40 follow-up: Changed at 2013-05-28T18:24:14Z by zooko

Great! We should try to turn these on in Tahoe-LAFS ASAP.

Hey, I remember that Brad Hill offered to support standardization of a CSP rule to restrict Referer leakage. What happened with that? Did we drop the ball on giving him some sort of spec doc?

comment:41 in reply to: ↑ 40 Changed at 2013-05-30T18:18:10Z by daira

Replying to zooko:

Hey, I remember that Brad Hill offered to support standardization of a CSP rule to restrict Referer leakage. What happened with that? Did we drop the ball on giving him some sort of spec doc?

We did. I'll try to get round to that.

comment:42 Changed at 2013-09-14T17:39:18Z by zooko

  • Keywords websec added

comment:43 Changed at 2015-01-21T19:01:22Z by warner

There's a new "meta referrer" header that's been proposed, which would allow websites to tell browsers to leave things out of the Referer header, or to omit it entirely. https://blog.mozilla.org/security/2015/01/21/meta-referrer/ . Still early, but if it gains momentum, we should turn it on.

comment:44 Changed at 2016-12-24T04:31:36Z by Brian Warner <warner@…>

In 639cc92/trunk:

Merge PR378: add some no-referrer tags

I think this fixes some, but not all, of the places where <a href> tags might
cause a browser to leak dircaps via the Referrer header.
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127 discusses more thorough
fixes.

refs ticket:127
refs tahoe-lafs/tahoe-lafs#151
closes tahoe-lafs/tahoe-lafs#378

comment:45 Changed at 2016-12-24T04:33:20Z by warner

There are some useful comments on PR-151 that should probably be considered, if this ticket doesn't already cover them.

Note: See TracTickets for help on using tickets.