Show HN: Sandbox.js - Run user code in a sandboxed environment | Hacker News Reader

Show HN: Sandbox.js - Run user code in a sandboxed environment

engineering.versal.com

31 pointsnicklovescode13 comments

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/

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

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)

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?

correct on both counts

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.

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.

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.

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.

You should be careful with subdomains. document.domain (https://developer.mozilla.org/en-US/docs/Same_origin_policy_...) 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.

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

You are specifically allowing the iframe to communicate with the parent window by specifying allow-same-origin in the sandbox attribute. Isolating code is a solved problem if you use a separate domain and allow the browser's cross domain policies to do their job.

Calling this Sandbox.js is pretty irresponsible. The term is well defined and well understood. You can't just use the name because it sounds nice.

nice¡ (;

Reply on news.ycombinator.com