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

New Issue

tahoe-lafs · 2009-10-28T04:03:18Z

davidsarah commented

2009-10-28 04:03:18 +00:00

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

A script (such as JavaScript) in an XHTML 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.

(http://allmydata.org/trac/tahoe/ticket/98#comment:22) A script (such as [JavaScript](wiki/JavaScript)) in an XHTML 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.

tahoe-lafs added the

labels 2009-10-28 04:03:18 +00:00

tahoe-lafs added this to the undecided milestone 2009-10-28 04:03:18 +00:00

davidsarah commented

2009-10-28 04:36:19 +00:00

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.

I believe this issue also applies to other scriptable file formats such as PDF and Flash. Possible solution: If the [NewCapDesign](wiki/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 commented

2009-10-28 05:03:18 +00:00

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.

This is a duplicate of #615 (Can [JavaScript](wiki/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.

zooko added the

duplicate

label 2009-10-28 05:03:18 +00:00

zooko closed this issue

2009-10-28 05:03:18 +00:00

davidsarah commented

2009-10-28 06:08:49 +00:00

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.

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.

tahoe-lafs removed the

duplicate

label 2009-10-28 06:08:49 +00:00

davidsarah reopened this issue

2009-10-28 06:08:49 +00:00

davidsarah commented

2009-10-28 06:38:38 +00:00

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

davidsarah commented

2009-10-28 06:49:32 +00:00

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

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

tahoe-lafs modified the milestone from undecided to 2.0.0

2010-03-09 22:15:25 +00:00

tahoe-lafs modified the milestone from 2.0.0 to 1.8.0

2010-04-12 19:17:53 +00:00

tahoe-lafs modified the milestone from 1.8.0 to soon

2010-08-08 05:32:09 +00:00

Sign in to join this conversation.