Re: Data URL Origin (Was: Blob URL Origin)

On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> * The default for this new flag is "false"
>> * If the flag is set to false, the origin of the URL is a unique identifier.
>> * When the origin is a unique identifier, it would not match any other
>> origin and so responses would always be tainted.
>> * If the flag is true, then the origin of the URL is equal to that of
>> the page that initiated the load.
>> * When the origin of the URL is inherited, it would always match the
>> origin of the caller, and so responses would never be tainted.
>
> This does not clarify what happens if you end up at a data URL as a
> result of a redirect. If the redirect is cross-origin you'll end up
> tainted. If it's CORS you get a network error. But if it's same-origin
> that's fair game?

For something like an <iframe> load I think the safe thing is to
always clear the flag when a redirect happens. I.e. if someone does

<iframe src="http://example.com/a" allowinheritingoriginfordataurlsplease>

and example.com redirects to a data URL, we would have all sorts of
messy questions if we allowed the flag to stay set an the origin to be
inherited:

* Should it be inherited from the owner of the iframe, who set the
allowinheritingoriginfordataurlsplease attribute, or from example.com
who is the one that generated the data URL. We don't want example.com
to get XSSed either.
* What if the owner of the iframe hadn't thought about redirects to
data URLs and just checked the src URL for data: and verified that it
didn't contain any bad stuff?

Redirecting to a data URL feels like a very edge-casy thing. So lets
keep it simple and safe rather than worry about cramming more features
in.

>> * I don't know what URL(data).origin should return.
>
> Probably just "null".

Given that the effective origin depends on which API you pass the
data-url to, I agree that trying to return a "real" origin here is
never going to be sensible. I don't know if returning "null" is the
way to go, or if returning `undefined` is. I guess I don't have a
strong opinion.

>> * Make APIs explicitly opt in to setting the "allow inheriting origin"
>> flag to true based on whatever policies that we decide.
>>
>> So for example we could make <img> always set the "allow inheriting
>> origin" flag to true.
>
> And for XMLHttpRequest? We decided a while back we wanted data URLs to
> work there.

I don't feel strongly.

>> For `new Worker(...)` I'm not sure what would be web compatible. I'd
>> prefer if the flag was set to false by default, but that the page
>> could use some explicit syntax (similar to the <iframe>) to opt in to
>> allowing inheriting.
>
> Given that workers execute script in a fairly contained way, it might be okay?

Worker scripts aren't going to be very contained as we add more APIs
to workers. They can already read any data from the server (through
XHR) and much local data (through IDB).

I'd definitely want them not to inherit the origin, the question is if
that's web compatible at this point. Maybe we can allow them to
execute but as a sandboxed origin?

/ Jonas

Received on Friday, 30 May 2014 00:08:35 UTC