Timeline for Using iframes to sandbox untrusted code
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 13, 2015 at 20:00 | comment | added | Thunderforge | The link to the demo no longer works. | |
| May 21, 2012 at 8:53 | comment | added | mgibsonbr | you're right, if they are invisible there's no need for them [to be iframes], a simple way to sandbox some code would suffice. I just added a small clarification in the question, but the main point is allowing (simplifying) the creation of new tools that will act on/make use of my model, even if they produce no (direct) visual effect. BTW thx for mentioning the html5 iframe sandbox, didn't know about it, and I can already see it opens some new, interesting possibilities (as long as it becomes widely supported, that is, which I hope is soon). | |
| May 21, 2012 at 7:33 | comment | added | user5575 | @mgibsonbr: wow that is pretty evil. One thing that has been bothering me is if in the case you cant see the iframe why have it at all? Browsers really need to support sandboxing. Actually chrome seems to handle my demo ok as long as allow-top-navigation isn't used (in the sandbox attribute) w3schools.com/html5/att_iframe_sandbox.asp | |
| May 21, 2012 at 6:38 | comment | added | mgibsonbr |
Thanks for the demo, it indeed confirms the iframe can mess with the parent site location. I know it's possible to have a good level of control over windows you opened yourself (using window.open for instance), and there are many nasty things an attacker can do with it, but I'm unsure whether or not any tab can control any other tab (I've seen many claims that the answer is no, and so far I found no evidence in contrary).
|
|
| May 20, 2012 at 8:30 | history | answered | user5575 | CC BY-SA 3.0 |