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

[davidsarah]

​http://allmydata.org/trac/tahoe/ticket/98#comment:22

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.

[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.

[zooko]

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.

[davidsarah]

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.

[davidsarah]

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

[davidsarah]

​http://allmydata.org/pipermail/tahoe-dev/2007-September/000134.html

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.)