1018872 - Implement stricter data URL policy

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect, P3)

Description

[Anne (:annevk)]

The threat vector here is people inserting URLs into things assuming that is safe. Inserting data URLs in contexts that execute script is unsafe as they could leak data from the origin.

To mitigate this data URLs should get a unique origin by default rather than inheriting an origin.

A few contexts will override this by default:

* <img>
* XMLHttpRequest

We need to investigate whether we can make this work for workers, there might be content depending on data URLs working there. We should still if we can at least sandbox the worker in that case.

To allow legitimate use we will introduce a flag (e.g. <iframe allowsameorigindataurl>) that allows for using the origin of the fetcher. I'll start a thread about this on the WHATWG list.

Context: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/thread.html#msg680

Comment 1

[Anne (:annevk)]

Per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3046 new Worker() throws when handed a data URL.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> To mitigate this data URLs should get a unique origin by default rather than inheriting
> an origin.

This is going to cause all sorts of compat problems. :(  Even ignoring the fact that our test suites rely on the current behavior all over, I expect we'd break a ton of addons.

If we want to do this, I wonder whether we can come up with a deprecation message here.  It can't be during the load; maybe during an actual access that gets allowed right now but wouldn't be under the new policy?

> Per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3046 new Worker()
> throws when handed a data URL.

You mean in non-Gecko browsers, right?

Comment 3

[Anne (:annevk)]

Message suggestion: "Using a data URL here will no longer work going forward due to a stricter security policy. See [this bug?] for details." We could advice people to migrate to blob URLs as security-wise they're less of a problem. There is the memory leak issue though.

And yes, I meant in Chromium, sorry.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Note that for both iframes and workers I think we should add some explicit syntax to allow data: URLs to work like they do today. Something like:

<iframe src="data:..." allowsameorigindataurls>

x = new Worker({ url: "data:...", allowSameOriginDataURLs: true });

But yes, the migration path here is going to be painful. We might be able to move faster on web-exposed content since they are less likely to depend on our current behavior as it's Gecko-specific.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Here's an email that describes the threat in more detail

http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0565.html

Comment 6

[Wladimir Palant]

I checked whether this would affect Adblock Plus. We use data: URLs for several things:

* nsIStyleSheetService.loadAndRegisterSheet()
* XMLHttpRequest
* nsIWindowWatcher.openWindow()
* <iframe type="content"> location

Only the last one seems problematic. Or would it be allowed since the frame doesn't inherit the security context here? I also checked my other extensions, no additional scenarios there.

Comment 7

[Mardeg]

Currently adding defer and async attributes to scripts requires the src attribute so how will using
<script src="data:.." defer async> be affected by this?

Comment 8

[Anne (:annevk)]

I talked to Mike West. He is not interested in <iframe allowsameorigindataurl>. They feel that is adequately addressed by <iframe srcdoc>. Letting data URLs wither is fine with him.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We could implement <iframe allowsameorigindataurl> anyway, given that it would be a step towards greater interoperability compared to our current policies. I.e. our current policies is to effectively always have the allowsameorigindataurl attribute set. So making the attribute an opt-in rather than a forced-always-set would at least make the default behavior interoperable.

Especially if the alternative is to do nothing due to concerns about compatibility with existing code (both internal and on the web).

Comment 10

[Anne (:annevk)]

The alternative is to encourage <iframe srcdoc> and get compatibility with Chromium and WebKit.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sure, srcdoc does and should continue to work like in other browsers.

My concern is that there has been absolutely no movement on making any changes to <iframe src="data:"> handling in Gecko. So now asking gecko to aim even higher and make an even bigger change, runs the risk that nothing will continue to happen.

I.e. all other states discussed here seems better than the current one. Aiming for the perfect one might leave us with the current one.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

But I'm all for encouraging people to use srcdoc. I'm not sure what that entails or who should do it. I'd be happy if you could drive it.

Comment 13

[Anne (:annevk)]

If we have resources, we should probably tackle this by context. E.g. for <iframe>:

1) Measure how often <iframe> ends up loading a data URL and the content is accessed afterwards (e.g. the actions that we would break by making it cross-origin).

2) Start warning for those scenarios.

3) Use warnings to clean up our tests and code. Most likely by using <iframe srcdoc> instead. (Alternatively do this earlier if there's some easy means to get to the affected files.)

4) Wait some period of time to see if usage goes down and then disable this.

Comment 14

[Boris Zbarsky [:bzbarsky]]

You can probably change our tests by just making the change and seeing what turns orange.

Comment 15

[Rob Wu [:robwu]]

Bug 1324406 has been resolved, and data:-URLs in frames use an opaque origin now.

Can this bug be closed now?

Comment 16

[Anne (:annevk)]

Yeah, I think we did most. Bug 1209102 is a follow-up.