- From: Devdatta <dev.akhawe@gmail.com>
- Date: Tue, 26 Jan 2010 20:55:14 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Collin Jackson <collin@collinjackson.com>, "Helen Wang (MSR)" <helenw@microsoft.com>, "public-web-security@w3.org" <public-web-security@w3.org>
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 04:56:06 UTC