[tahoe-dev] [tahoe-lafs] #615: Can JavaScript loaded from Tahoe access all your content which is loaded from Tahoe?

[tahoe-lafs]

#615: Can JavaScript loaded from Tahoe access all your content which is loaded
from Tahoe?
---------------------------+------------------------------------------------
     Reporter:  zooko      |        Type:  defect           
       Status:  new        |    Priority:  critical         
    Milestone:  undecided  |   Component:  code-frontend-web
      Version:  1.3.0      |    Keywords:  newcaps security 
Launchpad_bug:             |  
---------------------------+------------------------------------------------

Comment(by davidsarah):

 I believe I have a solution for this:

  * For file types that are not viewable in typical browsers, clicking the
 file link would download it as per #827. This limits the problem to the
 small number of types where not being able to view them directly in the
 browser is a significant usability problem ([X]HTML, images, and text).

  * Images and text are easy, since they don't contain scripts (provided
 that we can defeat browser sniffing that might cause it to treat files
 served as these types as something more dangerous).

  * The difficult problem is [X]HTML. For that case, we can serve a page
 containing a "parent script", and a full-page iframe with
 {{{src="javascript:child_script"}}}. {{{javascript:}}} URLs are (or should
 be) treated as having a special origin that does not compare equal to any
 other origin, even one for an identical URL. So now we have two scripts
 running in different origins that are able to obtain references to each
 other, which implies that they can communicate using a cross-origin comms
 technique such as Subspace (
 http://www.collinjackson.com/research/papers/fp801-jackson.pdf ). The
 parent script then loads the actual [X]HTML of the page using an
 {{{XMLHttpRequest}}}, and passes it to the child script, which rewrites
 its own frame with that content. The parent script shuts down the comms
 channel immediately after passing the content, so that scripts in the
 loaded page can't use it.

 (I originally thought that it would be possible to create a blank iframe
 using {{{src="about:blank"}}}, and have the parent script inject HTML into
 it directly using part of the technique described in http://softwareas.com
 /injecting-html-into-an-iframe . However, if that were possible then it
 would be a browser security bug, because you shouldn't be able to inject
 content into a frame with a different origin even if you have a direct
 reference to it. And we don't really want to rely on exploiting browser
 security bugs ;-)

 Anyway, I '''think''' this adequately isolates the injected page.
 Obviously it needs extensive testing in different browsers; we're relying
 on the fact that, although the injected page can obtain a reference to its
 parent (which has an origin shared by other WUI pages) using
 {{{document.top}}}, the same-origin policy shouldn't allow it to
 arbitrarily interfere with that parent (even though it can communicate
 with it). So this is not an example of the "sub-origin" approaches that
 are criticised in the Jackson/Barth paper.

 {{{img}}} tags in the injected page should still work because those aren't
 subject to the same-origin policy. (It would be a bug if web content could
 read the pixels of an image, but that wouldn't be a Tahoe-specific bug.)
 Similarly for nested frames or iframes in the injected page (the contents
 of these shouldn't be accessible to the injected page because their
 origins won't compare equal to the {{{about:blank}}} origin).

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/615#comment:8>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid