[tahoe-lafs-trac-stream] [tahoe-lafs] #1215: add CORS support

[tahoe-lafs]

#1215: add CORS support
-----------------------------------+---------------------------
     Reporter:  warner             |      Owner:
         Type:  enhancement        |     Status:  new
     Priority:  major              |  Milestone:  undecided
    Component:  code-frontend-web  |    Version:  1.8.0
   Resolution:                     |   Keywords:  security http
Launchpad Bug:                     |
-----------------------------------+---------------------------

Comment (by zooko):

 Replying to [comment:2 davidsarah]:
 > This is not safe. It would be safe if the web-API server provided no
 ambient authority, and was not subject to any DoS attacks. Unfortunately,
 neither of those conditions are true, since it provides ambient upload
 authority to a grid. The users of a web-API server may be relying on it
 only listening on particular IP interfaces or only being accessible from
 behind a firewall to mitigate this problem.

 I'm pretty sure that users do rely on this -- preventing other people from
 opening TCP connections to their gateway in order to prevent those people
 from using their storage space. If people could connect to your gateway,
 they could upload their own files from their computer into your tahoe-lafs
 storage space, and later retrieve the files again the same way (through
 your gateway). I could imagine unscrupulous people wanting to do that for
 file-sharing/hosting purposes (probably of the temporary kind -- until
 discovered and shut down).

 However, what vulnerability would turning on {{{Access-Control-Allow-
 Origin: *}}} open up? If I understand correctly, it is that someone could
 put up a web page, and somehow get you to visit it with the web browser
 that is also able to connect to your gateway. Then they could put a script
 on that web page that uses your storage space. This doesn't seem like as
 likely of a problem, because in order to upload their own files they would
 first have to arrange for those files to be transmitted into the
 Javascript memory running in your web browser or onto your local
 filesystem. Likewise, they couldn't directly download and view the files
 out of your storage space later, except by somehow proxying the data back
 down to your web browser and then back up to their server. That sounds
 like an R&D project to even get it to work, and it would be useless for
 the "file-sharing/hosting" use case mentioned above. If you can't usefully
 upload and download your own files, then what's left is just a denial-of-
 service -- uploading random files from the user's filesystem or all-zeroes
 files constructed in the memory of the Javascript program itself.

 This is not to say that David-Sarah's analysis is wrong. It is certainly
 right: the ambient authority is accessible to 3rd party scripts running in
 your web browser, if we allow those scripts to use Tahoe-LAFS. I'm very
 enthusiastic about fixing #587 and closing this vulnerability. But since
 the practical consequences of it, for now, seem limited, I tend to think
 it might be worth enabling 3rd party scripts to use Tahoe-LAFS now and see
 if any wonders grow there. :-)

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