Consider handling of javascript: urls in navigation

[otherdaniel]

Consider how to handle javascript: urls, e.g. in <a href="...">. Likely, these should be dropped unconditionally.

[mozfreddyb]

Ugh. Do we have to classify attributes according to their content (URLs for navigations, URLs for subresources, text, booleans)? The table at https://html.spec.whatwg.org/multipage/indices.html#attributes-3 is doing that, but it's a non-normative table, so there might be a risk of classifying attributes incorrectly when not reading all of the individual definition texts.

[mozfreddyb]

scratch that. @annevk tells me the table is non-normative because there's no real system of "types" that would be granular enough or even really well-exposed.. So, we have to do this by element + attribute name

[koto]

Trusted Types proposes a normative annotation for attributes that matter for XSS, though not URLs, we just added guards on navigation. In that sense, [StringContext] introduces "types" you might be looking for (but alas, it's not solving the javascript: URL problems). The other option that does not require hardcoding attributes in this spec would be to unconditionally block javascript: URLs at navigation (or all of unsafe-inline?) and only in this setting expose the Sanitizer - but then the output from the sanitizer can be used in other, unblocked, contexts.

[otherdaniel]

I've been explaining Sanitizer API to everyone as making security easier to use. So for Sanitizer - at least for Sanitizer v1 - my intent is have an easy-to-use and easy-to-explain config, and then handle whatever doesn't fit into that config as special cases in the specification. So far, <template> would fall into that category, and now javascript: URLs.

I understand that special casing stuff is inelegant, but prematurely generalizing the spec also has its costs.

If we find more such cases, or find such a mechanism generally useful, I think we can try to generalize the mechanism post-v1. (See also, #26)

I guess an alternative would be to use CSP to forbid javascript:-URLs outright, and to then ignore the matter in the Sanitizer. (A bit like koto said. Not sure if CSP already has the right toggle.)

[koto]

unsafe-inline toggle is a bigger hammer, in that it also disallows inline event handlers, and inline (non-nonced/hashed) script nodes. But I agree it's a but strange to simply ignore javascript: URL in Sanitizer and offload that to CSP, as you could make the same argument for all other vectors, and then the Sanitizer doesn't have to do anything, as there's CSP :)

[mozfreddyb]

I don't think we can depend the Sanitizer on anything that's defined in TrustedTypes.

[koto]

To clarify, I'm just saying that TT had a similar problem to solve, and we decided to do it via WebIDL extended attribute. Similar problems might benefit from a similar solution, and the IDL bit in specific is just a primitive we use to build TT guards on top of. I don't propose to introduce dependency on TT guard logic, policies etc.

[otherdaniel]

javascript:-URLs are apparently executed only during navigation. And navigate-y element/attributes are

• a.href
• area.href
• iframe.src
• base.href
• potentially embed + object, but we block those anyhow.

Surely there are more?

[mozfreddyb]

action= on form elements and formaction on various elements that belong to forms (input, button, what else?)

[otherdaniel]

Yes, thank you.

Also, my friendly colleagues pointed me to this list of navigate-y things: https://github.com/WICG/app-history#appendix-types-of-navigations

[otherdaniel]

iframe + embed + object are blocked anyhow. I'm unsure what to with base, since base doesn't directly navigate.

I've added a, area, form, and input to #63 as special cases.

[mozfreddyb]

#63