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

Re: [whatwg] Stricter data URL policy

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 2 Jun 2014 15:21:09 -0700
Message-ID: <CA+c2ei84orp-7inP4KoR9dNU6NiWYAPfRHS1ruMVb-HxNa0F=g@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: WHATWG <whatwg@lists.whatwg.org>
On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
>>
>> You're not persuaded by the attack scenario?
>
> Correct.  I mean, the same scenario applies to srcdoc, document.write() into
> an iframe, etc.  Why are data urls special?

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.

/ Jonas
Received on Monday, 2 June 2014 22:22:05 UTC

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