W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2015

Re: [whatwg] EventSource and data URLs

From: duanyao <duanyao@ustc.edu>
Date: Tue, 28 Apr 2015 03:35:37 +0000
Message-ID: <553F0009.6070600@ustc.edu>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@whatwg.org>
在 2015年04月28日 02:42, Jonas Sicking 写道:
> On Mon, Apr 27, 2015 at 7:37 PM, duanyao <duanyao@ustc.edu> wrote:
>> In iframe, srcdoc attribute seems as secure (insecure) as data: URL in src,
>> so should it be removed from the spec?
> The difference there, and in the other examples that you mention, is
> that you know that you are loading content in your own domain. The
> problem with data: URLs is that the same API sometimes does a network
> load, and sometimes parses content and runs in your security origin.
I understand now, thanks.
However, normal URLs from third parties to be rendered inside <iframe>s 
are not necessarily from different origins (e.g. blog or forum sites), 
so the attack
is still possible unless those sites explictly sandbox all iframes, or 
disallow iframes at all.

>
> I'm happy to have a way to opt-in to enable loading data: in <iframe>s
> and Workers. But I strongly prefer an explicit opt-in.
>
> Note that the chrome team apparently currently feels that data: in
> <iframe> is so unsafe that they always load it in a sandbox. And never
> allow data: in Workers. There's no way to even opt in to having it
> behave any other way.

How about blob: URL in Workers? Current chrome seems allowing it. I 
think it is less likely for Workers to run third party URLs as iframes  
-- after all, worker URLs must have same origin in the first place.

>
> / Jonas
Received on Tuesday, 28 April 2015 03:36:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:31 UTC