[tahoe-lafs-trac-stream] [tahoe-lafs] #1665: Brainstorm webapi vulnerabilities between the operator and a user and between users.

[tahoe-lafs]

#1665: Brainstorm webapi vulnerabilities between the operator and a user and
between users.
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  nejucomo               |     Status:  new
         Type:  task     |  Milestone:  undecided
     Priority:  major    |    Version:  n/a
    Component:  code-    |   Keywords:  docs security webapi introducer
  frontend-web           |  accounting status
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * cc: warner (added)


Comment:

 I think this one is currently solved with regard to authority over files
 (excluding authority over operations -- see "ophandles" below), at least
 if we exclude "cross-user scripting" or "cross-user reference forgery"
 issues.

 Replying to [comment:3 nejucomo]:
 > '''User vulnerabilities from other users.'''
 >
 > Capabilities may be leaked across browsers.  For example, one user, by
 browsing ongoing or completed operations may be able to acquire the
 capabilities used by another user.

 There is a Recent Upload Download page, but it doesn't use caps that grant
 more authority than the storage index does.

 > '''Mitigation brainstorm''': Restrict operation / status features such
 that only the user initiating an operation has a "capability" (distinct
 from the existing filesystem read/write/verify capabilities) to view the
 status of that operation.

 I think the current approach is even better: you can see the status of the
 operations of other users, but you can't get authority over the files
 involved.

 ''ophandles''

 This one could be problematic. See [source:docs/frontends/webapi.rst] for
 the docs about ophandles. They are chosen by the wapi client, so if the
 user's client software chooses guessable ophandles, then the user could be
 accidentally allowing other users of the same gateway to cancel their
 operations. I'm not sure if ophandles can be used for anything other than
 canceling and checking the status of operations. I propose we open a
 separate ticket for this specific issue -- ophandles could be guessable
 and gateways could be shared among users.

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