Timeline for Using iframes to sandbox untrusted code
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 10:46 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| May 22, 2012 at 2:44 | vote | accept | mgibsonbr | ||
| May 22, 2012 at 2:44 | comment | added | mgibsonbr |
Just created a small example that refutes my assumption in the comment above: in browsers that support sandboxed iframes, getting a reference to the window object (using event.source) does not enable it to change the browser location. That makes the iframe even safer than a separate window/tab, since the latter is not sandboxed, and becomes able to navigate my page away as soon as it receives a message from it.
|
|
| May 21, 2012 at 7:07 | comment | added | mgibsonbr |
Thanks for the feedback, especially for the links regarding JS sandboxing, I'll take a closer look at those. Your first bullet point is indeed what worries me most (see also this example of a possible exploit), and unfortunatly there's little I can do about it (postMessage will give the third-party page - regardless of being in an iframe or not - a reference to my window, so I believe they could still perform such attack). Overall I think the outlined risks are acceptable in my particular case, but if I can use one of those sandboxing tools, even better.
|
|
| May 20, 2012 at 23:35 | history | edited | D.W. | CC BY-SA 3.0 |
added 936 characters in body; added 250 characters in body
|
| May 20, 2012 at 23:28 | history | answered | D.W. | CC BY-SA 3.0 |