a <script src=> inside an <iframe sandbox=> is the same as a <sandbox src=>, the difference is that the later is only javascript, and the former is JS and HTML (and css maybe). If I understood correctly, Helen things that HTML is dangerous, since it executes in the context of the page serving it, while JS by itself is not.. Greetings!! -- Eduardo http://www.sirdarckcat.net/ On Wed, Jan 27, 2010 at 12:55 PM, Devdatta <dev.akhawe@gmail.com> wrote: > Hi Helen, > > It seems to me that your proposal and the HTML5 proposal are solving > different problems. This proposal talks about how to serve scripts > with null privileges while the HTML5 proposal is how to serve HTTP > resources (a.k.a HTML documents) with null privileges. > > Am I correct in thinking that whatever a script with null privileges > can achieve, an iframe sandbox can also achieve ? In particular, what > are the usecases that are covered by serving untrusted scripts but > aren't covered by serving untrusted resources ? > > Regards > Devdatta > 2010/1/26 Maciej Stachowiak <mjs@apple.com>: > > > > On Jan 26, 2010, at 2:44 PM, Collin Jackson wrote: > > > >> > >> Since there is no mechanism preventing the attacker from making an > >> iframe that points at the <sandbox>'s "src" attribute, the site needs > >> some way of preventing the content from rendering as HTML, even though > >> it will normally be script in non-attack scenarios. Serving up content > >> with the mime type text/javascript (or application/x-javascript) works > >> about as well as text/html-sandboxed (same IE6 and Flash caveats). > > > > Using a JavaScript type is likely to make some or all of the content > readable (and not just embeddable) cross-site. So even though it won't then > be rendered as HTML, this choice of MIME type has risks. > > > > Regards, > > Maciej > > > > > > > >
Received on Wednesday, 27 January 2010 05:37:33 UTC