Intent to Deprecate and Remove: `data:` URLs in `<base href>`.

[Mike West]

Primary eng (and PM) emails

mk...@chromium.org

Summary

`<base href="data:/,-alert(1)/">` causes `<script href="whatever">` to resolve to `data:/,-alert(1)/whatever`, which executes code before dying with an error. This doesn't make much sense, and (apparently) has zero non-malicious uses.

I'd like to remove the ambiguity between URL resolution (`data:` scheme with a path of `/,-alert(1)/`) and resource parsing (MIME type of `/` and a body of `-alert(1)/whatever`) by ignoring `data:` URLs in `<base href>`.

Motivation

https://bugs.chromium.org/p/chromium/issues/detail?id=689412 (as well as the earlier discussion at http://sebastian-lekies.de/csp/bypasses.php) use this mechanism to bypass CSP nonces. Restricting `data:` won't prevent this kind of attack (as attackers could certainly inject `<base href="https://evil.com/">` instead), but it does seem to be a pretty sane change that removes some surprising behavior.

Compatibility And Interoperability Risk

Based on quick experimentation with https://output.jsbin.com/zucihoraca:

* Safari matches Chrome's behavior.

* Edge ignores `data:` inside `<base>` (it tries to request the original resource)

* Firefox allows `data:` URLs in `<base>`, but doesn't request the resulting resource. I haven't dug into the details.

I've filed https://github.com/whatwg/html/issues/2249, and the reaction from Anne is ambivalent. IMO, aligning with Edge makes the most sense. *shrug*

Alternative implementation suggestion for web developers

Developers can use `https:` URLs in `<base>`. Or, you know, just not use `<base>`.

Usage information from UseCounter

`UseCounter::BaseWithDataHref` shows zero usage in the last week across Canary, Dev, and Beta channels.

OWP launch tracking bug

https://crbug.com/679318

Entry on the feature dashboard

Given the literally null usage, adding a feature entry seems like noise, but I'm happy to do so if folks disagree.

-mike

[PhistucK]

What do you think about emitting a rejectino warning every time such a code is encountered (not as a deprecation warning, but as a general one, even after the removal)? This can help mistaken developers (and save some time for malicious one ;P).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Boris Zbarsky]

On 2/8/17 5:10 AM, Mike West wrote:
> * Firefox allows `data:` URLs in `<base>`, but doesn't request the
> resulting resource. I haven't dug into the details.

Firefox always sets the "cannot-be-a-base-URL" flag on "data:" URLs.

-Boris

[Chris Harrelson]

LGTM1

[Dimitri Glazkov]

LGTM2.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

LGTM3

[Philip Jägenstedt]

I wasn't paying attention to the spec issue here and that the outcome was still unclear. I think we've often made small changes before the spec issue has been definitively settled, but when writing web-platform-tests together with the code, we would end up changing the test before the spec has changed, which was noticed at https://github.com/whatwg/html/issues/2249#issuecomment-278847830.

No biggie, but API owners should probably keep an eye out for this situation. If it's necessary to make the change before changing the spec, then we'd have to either write per-spec tests that deliberately fail until later updated, or just keep the tests outside of web-platform-tests in the interim.

[Jochen Eisinger]

It's true that there's a cyclic dependency between spec, implementation, and tests. Before we decide that this cycle should be broken by delaying the implementation / ship decision, I think we should have a dedicated discussion here. It's clear that for "predictability", specs and tests should come first, however, for other programs that's not as clear.

[Philip Jägenstedt]

To be clear, I am not saying that spec, tests and implementation must always move in lockstep, that we should necessarily have all 3 changes lined up before any of them are committed. In particular for a change with unknown compat implications, others may want to see it successfully shipped before the spec issue is ultimately resolved. For new features as well, prototyping is a fine thing.

What changes when we write web-platform-tests directly is that when the spec isn't ready, some extra work will be needed to make sure that those tests aren't upstreamed until the spec changes, and that it then matches the spec. Not sure what the best process would be really, maybe if we just give it a month or two it will become apparent.

[Jochen Eisinger]

ok, makes sense :)