Consider removing getPolicyNames()

[koto]

Pulling up a side-note as a separate comment:

With 'allow-duplicates' in place, I'd be a bit worried that

trustedTypes.createPolicy(trustedTypes.getPolicyNames()[0], {...}}.

becomes a common idiom to create policy without getting a security review.

It might be worth getting rid of getPolicyNames; it doesn't seem all that valuable. For detailed monitoring/telemetry a callback or event that can also see stack traces would be more appropriate.

Originally posted by @xtofian in #222 (comment)

[koto]

That would only work if the code runs within the environment where 'allow-duplicate'is used - so it's probably less probable in a library code.

I'm worried that removing this only gives the impression of security. Policy name is not designed to be a secret. Protecting secrets from Javascript code that runs in your realm is at least tricky, so we're trying not to go that way. For example, even if we removed getPolicyNames one can fetch() JS code (or read the inline script texts) and String.search for the policy name. Or, more practically, a name google-analytics or (window.jQuery ? 'jquery' : 'myapp') will be used. There are other legitimate places that would leak the name - e.g. the securitypolicyviolation event details.

In general, I'd like to stress out not to use policy names as the sole security controls - these are hints that let the app owner simplify the trust decisions, but they are not sufficient measures to stop authors determined to bypass the restrictions. With additional tooling names can be used in a mode that provides more security (e.g. when controlling what gets compiled into the application), but even that this will fall apart when dealing with malicious authors.

getPolicyNames() is probably less useful if we have an event for monitoring policy creation, but nevertheless it provides introspection into policy names

• that were used to successfully create a policy (ignoring the blocked policies)
• ... since the realm was created (and not since the event listener was installed)

so there is some value to it when compared to e.g. events.

[koto]

/ cc @xtofian

[xtofian]

I see your point about not giving the impression that policy names are secret. At the same time, it probably does matter in practice how easy a measure is worked around. Essentially, the purpose of these controls is not to strictly prevent a malicious developer from doing something nefarious, but rather to reasonably convincingly communicate to a non-malicious developer that they're doing something they shouldn't. In that light, a measure that can be worked around with a simple incantation such as `trustedTypes.createPolicy(trustedTypes.getPolicyNames()[0], {...})` is less convincing than something that requires workarounds involving event handlers or re-fetching JS and using regexen to parse policy names out of that.

…

On Mon, Nov 11, 2019 at 7:26 AM Krzysztof Kotowicz ***@***.***> wrote: / cc @xtofian <https://github.com/xtofian> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#235>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAPNDWHHD3TBOFLDQEHBATQTF2RDANCNFSM4JKVCR6A> .

[koto]

Essentially, the purpose of these controls is not to strictly prevent a malicious developer from doing something nefarious, but rather to reasonably convincingly communicate to a non-malicious developer that they're doing something they shouldn't.

That's opinionated, but for me it is already pretty clear that if there's an allowlist for getting access to some resource, then pretending you're on the allowlist is an intentional bypass - and if that's the intention, then all bets are off. An abuse of the API is indeed easier with getPolicyNames, but I think it's clear this is an abuse, and should be treated like one - in documentation, and other security controls like code review.

The policy name getter can always be constructed, even wrapped in a single function. e.g. (() => {addEventListener("securitypolicyviolation", e => {__p = e.originalPolicy.match(/trusted-types (\w+)/)[1]}, {once:1});try{location.href="javascript:__p = 'anything'"}catch(e){};return __p })(), it can even be a npm module so that the complexity is abstracted away.

In general, I'm worried it might be limiting for the future extension of the API if we decide to make it hard, or impossible to get the policy names from within the program. E.g. it might (in future) be helpful if a trusted type, or DOM attribute getter gave you information about which policy was used to create it.

That said, if we think getPolicyNames() delivers little value to the devs, I'm happy to remove it.

[koto]

We removed getPolicyNames, in favor of creating a proper introspection at policy creation time (possibly via events). Thanks!