Cap URLs leaked via HTTP Referer header

[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).

[zooko]

See also this e-mail thread about this:

​http://allmydata.org/pipermail/tahoe-dev/2007-September/000134.html

[zooko]

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.

[zooko]

See also #103.

[zooko]

Bumping this to v0.7.

[zooko]

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.

[zooko]

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.

[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)

[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."

[davidsarah]

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.)

[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.

[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.)

[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

[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>'"

[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 :-)

[zooko]

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.

[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).

[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.

[davidsarah]

Replying to davidsarah:

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

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

[davidsarah]

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.

[davidsarah]

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

[davidsarah]

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

[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.

[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 (edit: in a much simpler way than comment:21 ). I'll attach it here.

[davidsarah]

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

[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

[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?

[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!

[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.)

[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.

[zooko]

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

[warner]

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):

• ​http://wiki.whatwg.org/wiki/Meta_referrer
• ​http://www.schemehostport.com/2011/11/referer-sic.html
• ​http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
• ​https://bugzilla.mozilla.org/show_bug.cgi?id=704320

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

[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?

[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.

[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.

[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

[warner]

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