Hi, I’m the author of the underlying quickjs-emscripten runtime library. I like your ergonomic kind of “standard library” for quickjs-emscripten :)
Did you try running in the browser or with a bundler? I think accepting the variant name as a string you pass to import(variantName) dynamically may not play well with Webpack et al.
EDIT: SECURITY WARNING: this library exposes the ability for the guest (untrusted) code to `fetch` with the same cookies as the host `fetch` function. You must not run untrusted code if enabling `fetch`. Library should come with a big blinking warning about what is safe and unsafe to enable when running untrusted code. It’s not a “sandbox” if the sandboxed code can call arbitrary HTTP APIs authenticated as the host context!
The reason quickjs-emscripten is low-level and avoids magic is so I can confidently claim that the APIs it does provide are secure. I generally reject feature requests for magical serialization or easy network/filesystem access because that kind of code is a rich area for security mistakes. When you run untrusted code, you should carefully audit the sandbox itself, but also audit all the code you write to expose APIs to the sandbox.
In this case a comment from an other HN user asking about Fetch cookies tipped me off to the potential security issue.
Even if the fetch doesn’t have first-party cookies/authentication, there’s still there’s things to keep in mind depending on the trust level of the code. For example, is it okay for the untrusted code to access network services on the user’s localhost (like Zoom) or home network (like HomeAssistant, Philips Hue, WiFi router firmware)? These should be blocked by CORS and are sometimes blocked by the browser but it’s something to keep in mind. Phishing or exfiltration of data? Degrading experience or consuming the user’s bandwidth allowance by making too many requests? These concerns may or may not be relevant depending on use-case and the level of lockdown on the iframe. A good strategy is to allow-list the resources the iframe can fetch using content-security-policy, which is well supported in browsers and there’s a browser-level facility for receiving violation logs (although maybe that was phased out?).
Did you try running in the browser or with a bundler? I think accepting the variant name as a string you pass to import(variantName) dynamically may not play well with Webpack et al.
EDIT: SECURITY WARNING: this library exposes the ability for the guest (untrusted) code to `fetch` with the same cookies as the host `fetch` function. You must not run untrusted code if enabling `fetch`. Library should come with a big blinking warning about what is safe and unsafe to enable when running untrusted code. It’s not a “sandbox” if the sandboxed code can call arbitrary HTTP APIs authenticated as the host context!
The reason quickjs-emscripten is low-level and avoids magic is so I can confidently claim that the APIs it does provide are secure. I generally reject feature requests for magical serialization or easy network/filesystem access because that kind of code is a rich area for security mistakes. When you run untrusted code, you should carefully audit the sandbox itself, but also audit all the code you write to expose APIs to the sandbox.
In this case a comment from an other HN user asking about Fetch cookies tipped me off to the potential security issue.
More reading:
Figma blog posts on plugin sandbox security:
- https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...
- https://www.figma.com/blog/an-update-on-plugin-security/
Quickjs-emscripten README: https://github.com/justjake/quickjs-emscripten