6 ms·

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 se

by gitgud 3y ago

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...

seanwilson 3y ago
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/ https://codepen.io/ runs custom user JavaScript, HTML and CSS for example via iframes.
- cxr 3y ago
  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.)
  - seanwilson 3y ago
    Looks like `iframe sandbox` has been supported in major browsers for around 10 years though, including IE10.
    - cxr 3y ago
      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?
      - deleted 3y ago
        [deleted]
      - seanwilson 3y ago
        > 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 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.
        cxr 3y ago
        > 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?
cyanydeez 3y ago
Quickjs has a wasm module that seems like a solid sand box.

by gitgud 3y ago

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...

seanwilson 3y ago

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/ https://codepen.io/ runs custom user JavaScript, HTML and CSS for example via iframes.

cxr 3y ago
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.)
- seanwilson 3y ago
  Looks like `iframe sandbox` has been supported in major browsers for around 10 years though, including IE10.
  - cxr 3y ago
    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?
    - deleted 3y ago
      [deleted]
    - seanwilson 3y ago
      > 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 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.
      - cxr 3y ago
        > 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?

cyanydeez 3y ago

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