Re: [whatwg] Stricter data URL policy

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