[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 nejucomo):

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


 The above attack outline has several pieces and may not be entirely
 feasible.  However, I was interested in the problem and developed an
 "installer" portion of the above attack posted in #1859.

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