W3C home > Mailing lists > Public > www-archive@w3.org > September 2010

Re: @sandboxsrc proposal

From: (wrong string) ński <kornel@geekhood.net>
Date: Wed, 8 Sep 2010 11:14:35 +0100
Cc: www-archive@w3.org
Message-Id: <00FB7B0D-7F39-4AB8-A803-F36273ED04A4@geekhood.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On 7 Sep 2010, at 17:58, Tab Atkins Jr. wrote:
>> I'm not sure I understand what you're trying to say.
>> 
>> Yes, it's supposed to replace @srcdoc. And it allows embedding of content without network request:
>> 
>> <iframe sandboxsrc="data:text/html,no-network-request-here">
> 
> Oh, right, silly me.  Sorry about that.  Let's return to your original email.
> 
> In your original email, you said: "There were also suggestions that
> data: URIs already do what @srcdoc does, with the exception of
> fail-safety for sandboxed content in HTML4 UAs.".  That was *one* of
> the benefits of @srcdoc, yes.  The other benefit was that the escaping
> requirements were much simpler;

Yes, I'm aware of that. In practice you can use data: URI almost like @srcdoc, only adding "data:text/html," prefix to the value. This works in Firefox, Opera and Safari today (I can't test in IE):

<iframe src="data:text/html,<h1>Hello World</h1>">

They don't seem to mind spaces and unescaped <> in data: URI, even non-ASCII characters work fine (I guess that's HTML5 "URL" cleanup algorithm in action), so data: URI adds only few characters of boilerplate. 

It's not as good as @srcdoc, but OTOH @sandboxsrc avoids potential security issue you've raised and (strangely) I haven't seen critics of @srcdoc object to data: URIs.

> I won't go over them in detail as this
> has been discussed in depth before, but with @srcdoc you only have to
> escape a single character for security reasons, and if you fail to do
> so it will fail in an obvious manner fairly quickly on innocuous
> content.  data: urls have more complex escaping requirements, and if
> you do them incorrectly it may appear to be fine for innocuous content
> but expose you to an attack from malicious content.

Can you give me an example that is secure in @srcdoc, but not in data URI?

AFAIK to secure data: URI you don't need much more than for @srcdoc, i.e., you need to add "data:text/html," prefix (rather easy  it will fail visibly if you don't) and then escape quote to prevent content from escaping out of the attribute (same as @srcdoc). 

data: URI theoretically requires percent-escaping, but I don't see how failure to do so could cause security vulnerability in "data:text/html," content.

-- 
regards, Kornel
Received on Wednesday, 8 September 2010 10:15:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:33 GMT