Reconsider the origin of the document in <iframe src="data:...">

[mikewest]

https://html.spec.whatwg.org/multipage/browsers.html#origin defines the origin of a Document object "generated from a data: URL found in another Document or in a script" as "The origin of the incumbent settings object when the navigate algorithm was invoked, or, if no script was involved, the origin of the node document of the element that initiated the navigation to that URL."

Currently, Blink, WebKit, and EdgeHTML violate this requirement, instead placing things like <iframe src="data:..."> into a unique opaque origin. See the "willful violation" comment at https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/weborigin/SchemeRegistry.cpp?rcl=0&l=90, for instance.

For instance, https://output.jsbin.com/wofepos shows that Chrome, Safari, and Opera all reflect null as the origin of a message from a data: frame and deny DOM access, while Firefox reflects https://output.jsbin.com/ (the origin of the embedder) and allows DOM access. Edge 13 (which I'm stuck on because of exciting corporate update policy) reflects data:// (which is weird) and denies DOM access.

This tiny test, of course, is the tip of an iceberg.

[annevk]

Note that I think Mozilla in general is resigned to the fact that this is better, despite some folks not liking it too much: https://bugzilla.mozilla.org/show_bug.cgi?id=1018872.

[domenic]

It sounds like we should align the spec with the majority of implementations for this specific problem. However, I remain a bit confused about the issues discussed in whatwg/fetch#381 and what we want to do there. I guess they can be discussed separately?

[annevk]

Yeah, they are separate.

[foolip]

@sicking @bzbarsky @smaug----, would it fall of one of you to implement this change in Gecko, and are you OK with it?

[bzbarsky]

I have no plans to touch this stuff in Gecko. I doubt @sicking does either, since he's not currently actively working on Gecko.

I, personally, am still opposed to changing this at all. It makes no sense to me to treat data: and blob:/srcdoc differently here.

[annevk]

The attack vector is URL injection. Injecting a same-origin blob URL is hard as it would also require you to be able to execute script. You cannot inject srcdoc as a URL. Therefore data URLs are the only URL source that is vulnerable.

[foolip]

I tested https://output.jsbin.com/wofepos in Edge 14 via BrowserStack and it says "The origin of a data: frame is: data://, and access was denied." (Unsurprising, given that this was the case in Edge 13 too.)

We have a 3/1 split here, and aligning with the majority looks reasonable. But in terms of reaching interop, we can only claim success if Gecko actually changes, so @annevk, can you figure out who would actually make this change in Gecko?

@mikewest, can you open a web-platform-tests to test both the origin (failing on data://) and that access is denied? Writing the test itself is even better of course :) If you can then send it along to someone on the Edge team there's a good chance they'll fix it.

[annevk]

@foolip I don't think Gecko has the resources to change this anytime soon, especially given that @bzbarsky is not interested. Perhaps @overholt knows something I don't.

[mikewest]

FWIW, Gecko's approach is secure in itself. The data: URL's origin is inherited from the context triggering the navigation, and is safely cross-origin from the document into which it's been embedded. The vulnerabilities I've seen related to data: URLs almost universally relate to developer confusion caused by every other browser doing something different. That is, the developer will test in Chrome or Safari (or Opera (or Edge)), see the opaque origin, and say "Great! I can totally reflect user-controlled data in this spot without worrying about anything other than escaping!" Boom, Firefox-only XSS. I know this has happened to both Facebook and Twitter in the past, and would not be surprised it if happens again to other developers in the future.

If everyone had picked up this model a few years ago when it was added to the spec, this wouldn't be a problem. Not everyone did, however, and engines diverged. Regardless of whether this underlying divergence is principled or historical accident, it's real, and it causes real problems for developers. As frustrating as it will be for Gecko to change its behavior here, that seems more likely to be a path to interop than teaching Blink, WebKit, and EdgeHTML how to track origins for cross-frame navigation.

[mikewest]

Perhaps @hillbrad or @ptoomey3 could weigh in from a developer's perspective?

[hillbrad]

Nobody can depend on data: having same-origin semantics with its parent frame because it only works on Gecko. On the other hand, I have personally used this at Facebook to demonstrate XSS evasions of HTML sanitizers that worked only on Firefox because of this behavior.

If you want to play around, I built this thing awhile back to play with data/blob URIs in Workers and with sandboxing, it may be informative here as well to quickly show how different browsers handle such things in multiply-embedded cases.

http://webappsec-test.info/~bhill2/sandbox/matrix.html

[smaug----]

Pages have tons of browser specific code, so many sites may rely on same-origin semantic (and certainly many FF addons and tons of tests we have for Gecko relies on same-origin)

[domenic]

Another item for Gecko compatibility mode perhaps...

[foolip]

@smaug----, or someone who can speak with some authority for Gecko's DOM team, if we make this spec change, would you like to eventually attempt aligning with it, or would you prefer that we enshrine this lack of interop in the spec using the navigator compatibility mode? Since this isn't merely for feature detection like taintEnabled, I'd prefer to require one behavior so that web-platform-tests keeps telling us that there's a problem here.

[ptoomey3]

Nobody can depend on data: having same-origin semantics with its parent frame because it only works on Gecko. On the other hand, I have personally used this at Facebook to demonstrate XSS evasions of HTML sanitizers that worked only on Firefox because of this behavior.

Just came to say "me too"; I've only seen this quirk used to demonstrate Firefox specific XSS vectors.

[foolip]

OK, so I will go ahead and LGTM/merge #1756 and web-platform-tests/wpt#3663

It's still uncertain how things will work out for Gecko, but if making the change is Gecko is deemed too risky or is attempted and fails, then please check back here so we can look for some other way to reach interop.