Cap URLs leaked via HTTP Referer header #127

New issue

Open

opened 2007-09-04 16:16:50 +00:00 by warner · 36 comments

warner commented

2007-09-04 16:16:50 +00:00

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

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

warner added the

labels 2007-09-04 16:16:50 +00:00

warner added this to the undecided milestone 2007-09-04 16:16:50 +00:00

zooko commented

2007-09-17 21:55:56 +00:00

See also #103.

zooko commented

2007-10-13 06:35:25 +00:00

Bumping this to v0.7.

zooko modified the milestone from 0.6.1 to 0.7.0

2007-10-13 06:35:25 +00:00

zooko changed title from ~~smaller XSRF attack still possible~~ to smaller CSRF attack still possible

2007-10-15 18:49:54 +00:00

zooko commented

2007-11-01 19:43:04 +00:00

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

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

zooko added

v/0.6.1

and removed

v/0.6.0

labels 2007-11-01 19:43:04 +00:00

zooko commented

2007-11-13 18:35:47 +00:00

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 added

v/0.7.0

and removed

v/0.6.1

labels 2007-11-13 18:35:47 +00:00

zooko commented

2008-02-27 22:29:27 +00:00

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)

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

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 commented

2008-02-27 22:58:42 +00:00

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

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

zooko added this to the undecided milestone 2008-03-21 22:37:40 +00:00

warner modified the milestone from eventually to undecided

2008-06-01 20:47:43 +00:00

daira commented

2009-10-28 06:25:20 +00:00

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

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

daira added

p/major

and removed

p/minor

labels 2009-10-28 06:25:20 +00:00

daira changed title from ~~smaller CSRF attack still possible~~ to Cap URLs leaked via HTTP Referer header

2009-10-28 06:25:20 +00:00

daira commented

2009-10-29 06:11:29 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac/issues/127#issuecomment-362459): > <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.

daira commented

2009-10-29 06:34:50 +00:00

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

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

The behaviour of Mozilla browsers for the secure -> secure case is controlled by this preference ["rr" spelling]note: <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.)

daira commented

2009-10-29 06:44:55 +00:00

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

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 commented

2009-10-29 16:11:25 +00:00

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

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

daira commented

2009-10-29 19:04:43 +00:00

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

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 commented

2009-10-29 19:33:17 +00:00

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:362458, 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.

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:362458](/tahoe-lafs/trac/issues/127#issuecomment-362458), 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](wiki/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.

zooko changed title from ~~Cap URLs leaked via HTTP Referer header~~ to v

2009-10-29 19:33:17 +00:00

zooko changed title from v to Cap URLs leaked via HTTP Referer header

2009-10-29 19:37:53 +00:00

daira commented

2009-10-29 20:54:33 +00:00

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

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](wiki/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).

daira commented

2009-10-29 21:40:45 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac/issues/127#issuecomment-362474): > 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.

daira commented

2009-10-29 21:45:13 +00:00

Replying to [davidsarah]comment:21:

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

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

Replying to [davidsarah]comment:21: > ... send the read cap in the form data ... This approach would simultaneously fix #821. It would not fix #615.

daira commented

2009-10-29 23:46:47 +00:00

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.

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](wiki/JavaScript), I think that the fragment + form technique in comment:21 solves both.

daira changed title from ~~Cap URLs leaked via HTTP Referer header~~ to Cap URLs leaked via HTTP Referer header, and to phishing filters

2009-10-29 23:46:47 +00:00

daira commented

2010-01-17 14:54:27 +00:00

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

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

daira changed title from ~~Cap URLs leaked via HTTP Referer header, and to phishing filters~~ to Cap URLs leaked via HTTP Referer header

2010-01-17 14:54:27 +00:00

daira commented

2010-04-12 20:23:52 +00:00

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

daira modified the milestone from undecided to 1.8.0

2010-04-12 20:23:52 +00:00

daira self-assigned this 2010-04-12 20:23:52 +00:00

zooko modified the milestone from 1.8.0 to 1.9.0

2010-08-09 22:17:03 +00:00

warner commented

2010-12-25 00:15:58 +00:00

Author

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.

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.

daira modified the milestone from 1.9.0 to 1.10.0

2011-05-28 19:27:13 +00:00

daira commented

2012-09-13 03:38:32 +00:00

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.

daira commented

2012-09-13 03:41:40 +00:00

Attachment restrict-referrer-leakage.txt (5022 bytes) added

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

**Attachment** restrict-referrer-leakage.txt (5022 bytes) added Proposed Content-Security-Policy directive: "restrict-referrer-leakage"

restrict-referrer-leakage.txt

4.9 KiB

ChosenOne commented

2012-10-28 09:24:20 +00:00

Owner

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

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 commented

2012-10-28 16:35:39 +00:00

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?

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 commented

2012-10-28 16:36:37 +00:00

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!

daira commented

2012-10-29 17:49:50 +00:00

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

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

Replying to [ChosenOne](/tahoe-lafs/trac/issues/127#issuecomment-362488): > 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> [attachment:restrict-referrer-leakage.txt](/tahoe-lafs/trac/attachments/000078ac-0084-51a0-5e1e-9d426fff24e1) 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.)

daira commented

2012-10-29 17:50:45 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac/issues/127#issuecomment-362489): > 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 commented

2012-12-05 20:24:29 +00:00

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

warner commented

2013-05-28 17:42:25 +00:00

Author

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.

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 commented

2013-05-28 18:24:14 +00:00

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?

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 commented

2013-05-30 18:18:10 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac/issues/127#issuecomment-362495): > 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 commented

2015-01-21 19:01:22 +00:00

Author

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.

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@lothar.com> commented

2016-12-24 04:31:36 +00:00

Owner

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

In [639cc92/trunk](/tahoe-lafs/trac/commit/639cc92bcf59170aef1bb811c789412cf9c1da5f): ``` 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 commented

2016-12-24 04:33:20 +00:00

Author

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

There are some useful comments on [PR-151](https://github.com/tahoe-lafs/tahoe-lafs/pull/151) that should probably be considered, if this ticket doesn't already cover them.