

Show HN: Sandbox.js - Run user code in a sandboxed environment - nicklovescode
http://engineering.versal.com/frameworks/2012/11/30/Sandbox-js/

======
davidjohnstone
I haven't used it, but there's also Google's Caja, "a tool for making third
party HTML, CSS and JavaScript safe to embed in your website".

<https://developers.google.com/caja/>

------
arcatek
How is that a sandbox ? Evil users can use document.top to get the top-level
context. õ_o

~~~
nicklovescode
It's not really meant for security. As another comment stated they could just
hang the browser. It's more that page code doesn't get in the way of user
scripts. They're free to do $('a') or body { background: blue; } and only
affect their element(s)

~~~
arvidkahl
So it's a sandbox for the iframe, not a sandbox from the perspective of the
parent window object. For that, it's very useful. Have you looked into the
security/termination problems or are they not a neccessity for your project?

~~~
nicklovescode
correct on both counts

------
arvidkahl
I enjoy a simple little tool that makes embedding user content easier.

However, the problem with user-generated JavaScript is not security, it's
termination. To my knowledge, there is no 100% safe way to prevent a user
script from locking up the thread/tab/process without completely restructuring
it. Looking at you, Google Caja. Iframe solutions will reduce the attack
vectors to your page, but they will not keep it from locking up. So if you
have user-generated content that is displayed on your main page/feed, make
sure you don't allow JavaScript until there is a 99.5% sure way to determine
script lockup pre-execution.

------
krapp
Javascript objects can be overwritten though, can't they? A malicious user if
they succeed in getting their code into the same context just has to make sure
it runs after window.sandbox is initialized, and replace that with, say, null,
and then do whatever they want.

~~~
nicklovescode
yeah, a malicious user can do whatever they want using window.parent. It's not
for security, as far as I know there's not much that can protect against that.

~~~
arvidkahl
If you take the output, put that into a file on a different (sub-)domain and
request it as iframe src from there, you can use the Cross-Origin-Policy to
your advantage und have window.parent only respond to window.postMessage(),
not direct manipulation. This will secure your parent, but will still allow
for phishing inside the iframe.

~~~
underwater
You should be careful with subdomains. document.domain
([https://developer.mozilla.org/en-
US/docs/Same_origin_policy_...](https://developer.mozilla.org/en-
US/docs/Same_origin_policy_for_JavaScript)) allows a page strip the subdomain.
So pages on your supposedly safe third-party-code.example.com can act as
though their domain is plain old example.com.

~~~
eurleif
That only works if you explicitly set document.domain = "example.com" from the
pages on example.com, as well as from the pages on the subdomain. See:
<https://developer.mozilla.org/en-US/docs/DOM/document.domain>

------
mikebannister
nice¡ (;

