Re: Blob URL Origin

On Thu, May 22, 2014 at 1:45 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
>
> [...]

Thanks, I'm convinced.

So now I'd like to know what policy we want so we can carefully define it.

For blob URLs (and prolly filesystem and indexeddb) we put the origin
in the URL and define a way to extract it again so new
URL(blob).origin does the right thing.

For fetching blob URLs (and prolly filesystem and indexeddb) we
effectively act as if the request's mode was same-origin. Allowing
tainted cross-origin requests would complicate UUID (for the UA) and
memory (for the page) management in a multiprocess environment.


How do we deal with data URLs? Obviously you can always get a resource
out of them. But when should the response of fetching one be tainted
and when should it not be? And there's a somewhat similar question for
about URLs. Although only about:blank results in something per the
specification at the moment.


-- 
http://annevankesteren.nl/

Received on Thursday, 22 May 2014 08:30:09 UTC