logoalt Hacker News

kentonvyesterday at 8:50 PM3 repliesview on HN

We (Cloudflare OS) run an app's client-side code in a null-origin iframe sandbox that is denied access to everything that we can possibly deny access to. Its only communication line to the outside world is via a Cap'n Web RPC session over postMessage() to the parent frame, which in turn forwards the session on to the app's own server, which runs in a Dynamic Worker sandbox on its end. So the app client can only talk to the app server and nothing else.

Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.

So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.

(We would love to get those CSP holes plugged, though...)


Replies

william-evansyesterday at 9:01 PM

WebRTC is coming down the pipe into CSP hopefully soon: https://www.w3.org/TR/CSP3/#directives-other

FabianCarbonaratoday at 1:00 PM

I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.

The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).

What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().

For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.

danjm1today at 3:58 AM

In case you have not come across this it might be helpful:

MetaMask Snaps does something like Cloudflare OS's iframe sandbox, but it does aim to be suitable as a sandbox against malicious code.

Something of a security audit was published here: https://osec.io/blog/metamask-snaps/

Execution environment code here: https://github.com/MetaMask/snaps/tree/main/packages/snaps-e...

As it says in that readme, "sandboxed using Secure EcmaScript (SES)": https://github.com/endojs/endo/tree/master/packages/ses (which you might be familiar with, as it is a project of Endo, which Mark Miller helps lead)