W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Blob URL Origin

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 21 May 2014 16:45:06 -0700
Message-ID: <CA+c2ei9Ygc6ANwsNoL1GFfnQRwmFM4Mz58V8hPp9wiQEHFpg5g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
On Wed, May 21, 2014 at 3:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I think you are confusing issues. Or at least talking about two
>> separate issues at once in a way that I'm not sure what you are
>> talking about. The issue of "is there an XSS issue with treated blob:
>> like we treat data:" is a separate issue from "should we treat
>> cross-origin blob: like cross-origin http:, i.e. should we allow
>> pointing an <img> to a cross-origin blob:".
> Sure, I'm still at the "is there an XSS issue" here given that we can
> pass Blob objects around without restrictions.

The fact that we allow passing blobs around is no different from the
fact that we allow passing an ArrayBuffer or a string around. Once a
page knows that it has the blob/arraybuffer/string the only way to
have it XSS you is to eval() it. Hopefully pages know not to do that
when receiving a blob/arraybuffer/string from an untrusted party as it
pretty obviously will enable that party to XSS you. eval() always
*explicitly* runs code in your origin.

Likewise, if you receive a blob from an untrusted party, and then do
myscriptelement.src = URL.createObjectURL(blob), then that very
explicitly will run code in your origin. It should be no surprise that
that will cause an XSS risk and so hopefully pages know not to do

URLs are different though. If you receive a URL from an untrusted
party you can generally do window.location = url. Or you can do
myiframeelement.src = url and the worst thing you need to worry about
is that the contained page can navigate the top frame. And that you
can protect against by using a sandbox attribute.

It is not at all obvious that this can suddenly run code in your own origin.

Designing a secure platform doesn't mean forbidding any action that
can cause bad things to happen. Doing that might create a secure
platform, but one that probably can't do anything interesting.

Designing a secure platform is done by making things that can be
insecure be very explicit about what they do. So if someone wants to
do something that might be insecure that they have to very explicitly
ask for that. Hopefully that will cause them to think twice about it
and take any necessary precautions first.

/ Jonas
Received on Wednesday, 21 May 2014 23:46:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC