Hacker News Reader

Comment by simonw | Hacker News Reader

I've been trying to figure out the right pattern for running untrusted JavaScript code in a browser sandbox that's controlled by a page for a while now, looks like Anthropic have figured that out. Hoping someone can reverse engineer exactly how they are doing this - their JavaScript code is too obfuscated for me to dig out the tricks, sadly.

View on HN

The key is running the untrusted code in a cross-origin iframe so you can rely on the same-origin policies and `sandbox`[1].

You can control the code in a number of ways - loading a trusted shim that sets up a postMessage handler is pretty common. You can be careful and do that in a way that untructed code can't forge messages to look like their from the trusted code.

Another way is to use two iframes to the untrusted origin. One only loads untrusted code, the other loads a control API that talks to the trusted code. You can then to the loading into the iframe with a service worker. This is how the Playground Elements work (they're a set of web components that let you safely embed a mini IDE for code samples) https://github.com/google/playground-elements

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

The cross origin iframe method is the same I’ve employed in A few browser extensions I’ve built

You should check out how Figma plugins work. They have blog posts on all the tradeoffs they considered.

What I believe they settled on was a JS interpreter compiled to WASM -- it can run arbitrary JS but with very well-defined and restricted interfaces to the outside world (the browser's JS runtime environment).

> We now use QuickJS, a JavaScript VM written in C and cross-compiled to WebAssembly.

https://www.figma.com/blog/an-update-on-plugin-security/

Yo dog, we put a JavaScript VM inside your JavaScript VM

Much easier in the browser that has V8 isolate, however even with webworkers you still want to control CPU/network hijacking which is not ideal.

If it's only the user's own code it's fine but if they can run code from others it's a massive pain indeed.

On the server it's still not easy in 2024, even with Firecracker (doesn't work on mac), Workerd (is a subset of NodeJS), isolated-vm (only pre-compiled code, no modules).

Isn’t that how all JavaScript code runs in a browser?

Isn't what how all JS runs in the browser? There are different restrictions based on where JS comes from, and what context it gets loaded into.

All browser js runs in a browser sandbox and, by default, none of it needs to be explicitly trusted in most browsers.

I don’t think there are very many restrictions on what js can do on a given page. At least none come to mind.

Not really sure you mean by “context” either. Maybe service workers? Unless you’re talking about loading js within iframes… but that’s a different can of worms.

You've misunderstood the GP's question. If you read the other answers you might understand what he's asking. Hence exactly why they're all talking about iframes.

You used to be able to do it quite easily, but it meant people could essentially impersonate the user if you got them to execute some javascript. So having a code editor would be a recipe for account hijacking.

So gradually browsers locked it all down. Long gone are the days of just doing 'eval()'. In the 2000s I worked on code where we actually did that!

Ah, the days of getting away with massive security holes that no-one even knew how to exploit.

> If you read the other answers you might understand what he's asking

Dude, relax. There were no other comments when I asked…

What are the attack vectors for a web browser js environment to do malicious things? All browser code is sandboxed via origin controls, and process isolation. It can’t even open an iframe and read the contents of that iframe.

It's a fine place to run code trusted by the server (or code trusted by the client within the scope of the app).

But for code not trusted by either, it's bad -- user data in the app can be compromised/exfiltrated.

Hence for third-party plugins for a web app, the built-in JS runtime doesn't have sufficient trust management capability.

The attack vectors are either some type of credential or account compromise. Generally, these attacks fall under the cross-site scripting (XSS) umbrella. The browser exposes certain things to the JS context based on the origin. E.g. if you log in to facebook.com, facebook.com might set an authentication cookie that can be accessed in the JS context. Additionally, all outbound requests to facebook.com will include this authentication cookie. So, if you can execute JS in the context of facebook.com, you could steal this cookie or have the browser perform malicious actions that get implicitly authenticated.

commenting to save this for later

I used this technique until someone told me that you can use the upvote arrow and find these in your profile

You can also click on the post and then favorite them, but favorites are public.

Reply on news.ycombinator.com