Re: [whatwg] Stricter data URL policy

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