#821 assigned defect

A script in a file viewed through the WUI can obtain the file's read cap

Reported by: davidsarah Owned by: davidsarah
Priority: major Milestone: soon
Component: code-frontend-web Version: 1.5.0
Keywords: newcaps newurls confidentiality capleak websec Cc:
Launchpad Bug:

Description (last modified by zooko)


A script (such as JavaScript) in an [X]HTML file viewed through the WUI can obtain the read cap for that file. For an immutable file, this is not much of a problem because the script can read the contents of the file anyway. However, for a mutable file, it can also read any future version, which is a violation of the Principle of Least Authority.

Change History (13)

comment:1 Changed at 2009-10-28T04:36:19Z by davidsarah

I believe this issue also applies to other scriptable file formats such as PDF and Flash.

Possible solution:

If the NewCapDesign implements versioned read caps (i.e. read caps that only give access to a specific version of a mutable file), then that would allow versioned read URLs to be used by default by the WUI.

That would also have the side effect that cutting-and-pasting an URL from the address bar would only give access to a single file version by default (and the versioned URLs could also provide collision resistance). I'm not sure whether that is what users would expect, but it is a safer default.

I think this would have to work by having the gateway perform an HTTP redirect from the unversioned read URL to the versioned one (probably conditional on a parameter in the URL). The parent directory listing cannot directly link to the versioned URLs because that would require reading every file in the listing, which would be too inefficient.

comment:2 Changed at 2009-10-28T05:03:18Z by zooko

  • Resolution set to duplicate
  • Status changed from new to closed

This is a duplicate of #615 (Can JavaScript loaded from Tahoe access all your content which is loaded from Tahoe?). Perhaps David-Sarah, who is an expert on such things, could retitle #615 and copy in their comments from this ticket.

comment:3 Changed at 2009-10-28T06:08:49Z by davidsarah

  • Resolution duplicate deleted
  • Status changed from closed to reopened

It's not really a duplicate, because #615 is about scripts from one page having access to other pages. If #615 were fixed, this issue would remain, since it isn't dependent on the same-origin policy. That is, even if we were to put every page in a different origin, a script would still be able to access its own URL -- and therefore future versions of its file if this bug is not fixed.

In a sense, #615 masks this bug, because it allows an attack that is a superset of this one. So I think we should leave this ticket open and reference it from #615.

comment:4 Changed at 2009-10-28T06:38:38Z by davidsarah

If you like this bug, you might also like #127, about cap leakage via the HTTP Referer header.

comment:5 Changed at 2009-10-28T06:49:32Z by davidsarah


After the cap-talk meeting, Brian and I agreed -- I thought -- not to bother making the URL field read-only, and instead to document the fact that sharing a URL will (by default) share write access to your directory as well as read access.. Apparently Brian remains interested in a JavaScript hack to read-only-ify URLs after loading them.

When using the WUI, is it only for directories that the URL will represent a write cap? (Directory listings do not contain untrusted scripts, so this bug shouldn't be a problem in the directory case.)

comment:6 Changed at 2009-10-28T07:29:08Z by davidsarah

  • Keywords newurls added

comment:7 Changed at 2009-12-04T04:27:45Z by davidsarah

  • Keywords confidentiality added

comment:8 Changed at 2010-01-17T14:57:00Z by davidsarah

  • Keywords capleak added; security removed

comment:9 Changed at 2010-03-09T22:15:25Z by davidsarah

  • Milestone changed from undecided to 2.0.0

comment:10 Changed at 2010-04-12T19:17:53Z by davidsarah

  • Milestone changed from 2.0.0 to 1.8.0
  • Owner set to davidsarah
  • Status changed from reopened to new

comment:11 Changed at 2010-04-12T19:18:06Z by davidsarah

  • Cc david-sarah@… removed
  • Status changed from new to assigned

comment:12 Changed at 2010-08-08T05:32:09Z by davidsarah

  • Milestone changed from 1.8.0 to soon

comment:13 Changed at 2013-09-14T17:39:49Z by zooko

  • Description modified (diff)
  • Keywords websec added
Note: See TracTickets for help on using tickets.