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

Old description:

> If the webapi client emitted a header like this on every page:
>
> {{{
> Access-Control-Allow-Origin: *
> }}}
>
> Then, in sufficiently-modern browsers, web pages pulled from arbitrary
> third-party sites would be able to perform XHR to the Tahoe webapi server
> without interference by the regrettable "same-origin policy".
>
> Clients who want to use this (i.e. web pages from third parties) must do
> a slightly different form of XHR than usual: I'm looking at
> [http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-
> origin-resource-sharing/ this] and [http://softwareas.com/cors-scraping-
> and-microformats this] for details.
>
> One quirk to keep in mind is that clients (i.e. those third parties) can
> set a flag on their XHR calls to cause the browser to include any cookies
> that the tahoe webapi might have set. We all know to not use cookies for
> authorization, but once we enable CORS, we should make extra sure to not
> add any code which accepts authority information from cookies.

New description:

 If the webapi client emitted a header like this on every page:

 {{{
 Access-Control-Allow-Origin: *
 }}}

 Then, in sufficiently-modern browsers, web pages pulled from arbitrary
 third-party sites would be able to perform XHR to the Tahoe webapi server
 without interference by the regrettable "same-origin policy".

 Clients who want to use this (i.e. web pages from third parties) must do a
 slightly different form of XHR than usual: I'm looking at
 [http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-
 origin-resource-sharing/ this] and [http://softwareas.com/cors-scraping-
 and-microformats this] for details.

 One quirk to keep in mind is that clients (i.e. those third parties) can
 set a flag on their XHR calls to cause the browser to include any cookies
 that the tahoe webapi might have set. We all know to not use cookies for
 authorization, but once we enable CORS, we should make extra sure to not
 add any code which accepts authority information from cookies.

--

Comment (by nejucomo):

 Replying to [comment:7 zooko]:
 > Replying to [comment:6 davidsarah]:
 > >
 > > > However, what vulnerability would turning on Access-Control-Allow-
 Origin: * open up?
 > >
 > > An XHR request is indistinguishable to the gateway from any other
 request, so the consequence is that an attacker who can run any script in
 the user's browser -- not only scripts loaded from the gateway's origin --
 can do anything that the user can do with that gateway. (Because the
 gateway does not support "preflight" checks, this is limited to GETs and
 to POSTs of MIME types {{{application/x-www-form-urlencoded}}},
 {{{multipart/form-data}}}, and {{{text/plain}}}, but that's not much of a
 restriction in our case.)
 >
 > Okay, thanks for the explanation. Am I right, in comment:5, that giving
 an attacker this power would not enable the attacker to perform the "steal
 your storage for my temporary file-sharing" use case?

 I think it's quite possible for an attacker to use a victim's tahoe for
 their own storage:

 1. Site evil.example.com hosts two javascript payloads: The "installer",
 and the "daemon".
 1. victim visits evil.example.com and loads the installer, which detects a
 tahoe gateway.
 1. The installer uses ambient upload authority to upload the daemon into
 the tahoe grid.
 1. The installer directs the browser to open the daemon.
 1. The daemon performs several tasks:
   * It collects the victim's file-write capabilities (I'm not certain how
 feasible this is, but assume it can discover at least one capability)
   * For each write cap found, it rewrites that file to include a copy of
 itself.
     * The purpose of this is to increase the chance that this daemon will
 execute in the future without requiring the original evil.example.com
 vector.
     * It's easy to imagine rewriting html, but perhaps, under the
 assumption that the storage is backups of local file system data, it could
 also modify shell scripts or anything else which may be an execution
 vector.
   * It periodically polls an attacker controlled site waiting for
 download/upload commands or other commands.

 I don't think the "inconvenience" of shuttling data through a victim's
 browser is any worthwhile barrier; it just depends on the relative costs
 of bandwidth, latency, storage, and lulz.  The existence of millions of
 botnet zombies attest to their own value.  ;-p

 It's true that setting up this kind of system is some R&D work, but I'd
 bet a grey-hat who's familiar with javascript could figure out every
 component of the above system within several hours, except perhaps CAP
 discovery.

 Notice that without cross domain access, an attacker with grid access can
 replace steps 1-4 with:

 1. The attacker uploads the daemon payload into the grid.
 1. The attacker tricks the victim into opening that daemon from tahoe in a
 js-enabled browser.

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