[tahoe-lafs-trac-stream] [tahoe-lafs] #127: Cap URLs leaked via HTTP Referer header

[tahoe-lafs]

#127: Cap URLs leaked via HTTP Referer header
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  davidsarah
         Type:  defect   |     Status:  assigned
     Priority:  major    |  Milestone:  1.11.0
    Component:  code-    |    Version:  0.7.0
  frontend-web           |   Keywords:  confidentiality integrity
   Resolution:           |  preservation capleak research
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

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

New description:

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

--

Comment (by 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127#comment:39>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage