W3C home > Mailing lists > Public > public-web-security@w3.org > January 2010

Re: text/sandboxed-html

From: Devdatta <dev.akhawe@gmail.com>
Date: Tue, 26 Jan 2010 20:55:14 -0800
Message-ID: <ecf35a1b1001262055q7c6cd214hb0bba61f5d832777@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:02 GMT