W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Stricter data URL policy

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 9 Jul 2014 20:22:53 -0700
Message-ID: <CA+c2ei_NOCT7ohBSXM_4cQ9nErN6RG+BuSMTcw9nPZGn3O3Ttg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jul 3, 2014 at 10:00 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> srcdoc is like eval(). Yes, it's definitely a tool that enables you to
>> run 3rd party code in your own context and with your own principal.
>> However whenever you use the feature you (should) know that it's
>> running code in your own context and with your own principal. So
>> hopefully pages will make sure to not pass untrusted 3rd party code to
>> neither srcdoc nor eval().
>>
>> We've seen this happen internally in Gecko where chrome code will get
>> XSSed by being tricked to load data URLs. And I've been trying to move
>> us towards only allowing data: to run with a chrome principal if
>> chrome code explicitly opts in to that.
>>
>> I don't see why websites wouldn't face the same challenges and why the
>> same solution wouldn't work there.
>
> What about:
>
>   <iframe src=javascript:alert(top.document.title)></iframe>
>
> It seems that has the same issue.

Yes, it has the same issue.

But javascript: is sort of screwed no matter what. A javascript URL
inheritely will run javascript, and it always does so in the origin of
whoever set the url. So pages will have to look for javascript:
anytime they are handling URLs.

But it's better if pages only have to look for javascript: when
handling URLs. Rather than having to look for javascript:, data:,
blob: and nextbigthing:.

I'd love to simply deprecate javascript:. It doesn't seem like the use
cases are worth the complexity for both implementations and authors.
But I think it's too commonly used these days to get rid of. At least
for quite some time. About 100x the usage of sync XHR if [1] means
that I guess it means.

[1] http://www.chromestatus.com/metrics/feature/popularity#ReplaceDocumentViaJavaScriptURL

/ Jonas
Received on Thursday, 10 July 2014 03:23:48 UTC

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