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

[tahoe-lafs]

#127: Cap URLs leaked via HTTP Referer header
-------------------------------+--------------------------------------------
 Reporter:  warner             |           Owner:           
     Type:  defect             |          Status:  new      
 Priority:  major              |       Milestone:  undecided
Component:  code-frontend-web  |         Version:  0.7.0    
 Keywords:  security           |   Launchpad_bug:           
-------------------------------+--------------------------------------------

Comment(by davidsarah):

 Replying to [comment:20 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.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/127#comment:21>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid