[tahoe-dev] How to use Caja to solve the same-origin policy hazard (hosting both webapps and untrusted content in Tahoe)

[Brian Warner]

On 7/29/11 5:39 PM, Kevin Reid wrote:

> Given the two origins, the only way you are in danger is if you have
> two “raw” (from origin #2) documents open in your browser at once

The tab's history is also an angle of attack, so I think another danger
is to open two different documents in sequence in the same tab (perhaps
doc1 has a link to doc2 and the user follows it), and the vulnerability
is that the code in doc2 could learn the filecap of doc1.

> This scheme also has a nice division to it: Origin #1 serves only
> content generated by Tahoe-or-Caja; Origin #2 serves only arbitrary
> uploaded content.

I like it. I'm not willing to add Java to Tahoe's dependency set, but
I'm happy to say that you only get these protections if you're running
an ES5-capable browser (and using the JS-only cajoler), and older
browsers remain vulnerable to cross-document attacks (just as they are
now unless you use NoScript/etc against your WUI).

I'm not sure that "rewritten by Caja" is a sufficient description of
what needs to be done, since cajoling merely adds confinement, without
necessarily establishing the bridges that let the now-confined code do
something useful. As you pointed out, what this actually needs is a
simple Caja+(single-page-viewer) function, in which confined code that
only uses a well-known subset of the usual page authority will continue
to work normally. Code which reaches outside that set should fail.

What exactly is that subset? What parts of the "usual page authority" do
we want to deny? Certainly the ability to script other windows (normally
granted by window.opener or a guessable window name when the target has
the same origin). Also the ability to read the history or current URL
out of other windows. Those are the two main attack vectors we've
examined so far. We can probably leave the app full control over the
window's DOM, and XHR, as long as the membrane keeps it from leveraging
that into unconfined eval.

I've always thought of Caja itself as a tool to build sandboxes with
specific powers, but of course the Caja project must also have other
tools to define some useful types of sandboxes. I don't know where those
other tools are or how you express that control.

> [Disclosure: I am currently being paid to work on Caja.]

Being paid to work on Caja means you probably actually know how to pull
this off :). It's too easy for the rest of us to imagine that "run all
pages through Caja" is some sort of magic security dust that can be
sprinkled onto HTML to "make it all safe", and you're just the sort of
person to help us clarify what'd we'd actually need. So I think it's a
good thing :).

cheers,
 -Brian