mozilla/friendlycode — pull request #162 by toolness (2012-11-26 16:13:08+00:00)
Title: Sandbox the live preview inside an iframe on a separate origin

This isn't yet a formal pull request with productionalized code; it's more to begin a dialogue.

The [risk considerations](https://wiki.mozilla.org/Webpagemakerapi) documented on the Mozilla Wiki before development began on Thimble, back in spring of this year, mentions that "Javascript could be used in a multitude of ways to compromise client machines", and that the mitigation strategy is "All Javascript will be stripped using Bleach before it is served."

One such vector of using JS to compromise client machines is to execute arbitrary code on the domain that Thimble is hosted on, e.g. [thimble.webmaker.org](http://thimble.webmaker.org/). The code contained in this pull request is a proof-of-concept which houses the live preview on a separate origin that is communicated with via [postMessage](https://developer.mozilla.org/en-US/docs/DOM/window.postMessage). A simple message-passing protocol is defined that treats the preview frame as untrusted, thereby mitigating any attacks that malicious code can inflict on the editor domain.

I've hosted a demonstration of this at [sandboxed-jsthimble.toolness.org](http://sandboxed-jsthimble.toolness.org). There shouldn't be any way to access the editor frame from script that the preview frame executes. This demonstration only uses a single domain for executing untrusted JS, but we can also use separate subdomains for each published Thimble page, which would prevent different pages from corrupting each others' states.

I'm curious if this measure is enough to mitigate the use of JS to compromise client machines. What ways can JS be used to compromise client machines when it's executed on a separate origin that's sandboxed from other content?