Hacker News Reader

Comment by tommiegannert | Hacker News Reader

What are your security concerns?

Code in the cells breaking out and manipulating the page where they are embedded.

don't upload malicious code in your blog then. The same thing happens when you import a 3rd party library. I see this as a feature not a bug.

Pretty sure adding a JS interpreter in your webpage is impossible to do without security concerns...

But maybe using an <iframe> would make it a little more secure...

What's the worst that could happen with an `<iframe sandbox="allow-scripts">` on your page (where the iframe will be treated as if it's from a different origin to the current page)? https://codepen.io/ runs custom user JavaScript, HTML and CSS for example via iframes.

Like CSP, iframes' sandbox attribute was conceived for an environment where it only works as part of a defense-in-depth strategy. It had to be; iframe is not a completely new element—consider what things looked like the day after the first browser to support the sandbox attribute was released: you had some X% of users who would be protected by it, and some Y% who would not, where Y >> X, and the set of people belonging to Y weren't "wrong" for belonging to that set—an author expecting sandbox to be the first, last, and only line of defense against malicious code is the one in the wrong. (Same with CSP.)

Looks like `iframe sandbox` has been supported in major browsers for around 10 years though, including IE10.

That doesn't change the fundamental character of sandbox being one part of a defense-in-depth strategy instead of being the first-last-and-only line of defense. When you begin using and relying on a security-related feature in a way it was never designed to be used, then you are playing with fire and arguably already compromised. Browser vendors can change their implementation at any time on the basis that newer releases still satisfy the intent.

Example: what approach are you using in your hypothetical to actually get the cell contents into the iframe?

> in a way it was never designed to be used

Most of the evolution of web dev can be described as people pushing the boundaries of what browsers were meant to do until standards caught up. I think iframes for running untrusted content is very standard now (https://caniuse.com/iframe-sandbox) with a lot of well supported safe guards built-in like treating the iframe as its own origin.

Obviously defense-in-depth is a good idea and you should be careful when setting up iframes, but if there's a good chance `iframe sandbox` is going to break in later browser releases, there's a lot of stuff you couldn't do anymore. Even with CSP, it would only reduce but not eliminate what an attacker could do.

> if there's a good chance `iframe sandbox` is going to break in later browser releases

That's not what I said.

Can you answer the question?: What approach are you using in your hypothetical to actually get the cell contents into the iframe?

Quickjs has a wasm module that seems like a solid sand box.

As long as a user can only run the code they (or the page author) has entered by themself, I don't see an issue. It gets more problematic if you allow users to store modified cells and link to them. Then a malicious user could write a cell amd trick another user into executing it.

Reply on news.ycombinator.com