New `trusted-types-eval` keyword for CSP script-src about standards-positions HOT 9 OPEN

I think my main issue with this is that it's only as trusted as the policy, which might well be crap, but that's a general problem with Trusted Types that's no longer fixable. Although given the other directives have the trusted-types-* prefix (based on w3c/webappsec-csp#659) this should probably have that too, to make it clear it's not more special than any of that.

The other discomfort I have is that in #186 the main motivation for this feature that was brought forward was a way to avoid having to specify unsafe-eval as certain regulation would prohibit that. Which raises the question how hard either of these policies make it to execute script despite the policy being in place. E.g., you have a CSP header in place for regulatory reasons, but you don't actually care much for the potential upsides as you have a deadline to meet and just want to execute some script. I suspect that in both cases you can recreate "unsafe eval", but it's probably a little bit more straightforward with Trusted Types if your default policy blesses any string you pass it.

Modulo a more Trusted Types-aligned name it's probably okay, though I'd be curious to see more analysis of this from other people.

cc @sysrqb @johnwilander

from standards-positions.

But strict-dynamic obsoletes unsafe-eval.

This is a misunderstanding of what strict-dynamic allows. Today CSP requires 'unsafe-eval' for use of eval.

from standards-positions.

See #186 for the base position request on Trusted Types as a whole.

from standards-positions.

@annevk with respect to the discussion about regulations, I have few comments, but first, few general thoughts on regulations:

1. By definition, regulators have to evolve their rules as technology evolves, and companies that are regulated are responsible for pushing back on outdated regulations. But this is a two way street.
2. I haven't seen a regulation that applies only to a particular browser, or a particular version of a browser, they are often vague with respect to the browsers support matrix. This is often in directly-conflict with the way we (standard folks) see the web evolution, we often focus more on backward compatibility and the "do not break the web" mantra.
3. There is often a fine-line between complying with "the spirit of the regulation" vs "the letter of the regulation". I think we (standard folks) should focus more on the former.

With respect to this particular proposal:

1. The specific manifestation of the conflict is that browsers without TT are completely open to the attack surface that the regulation is attempting to regulate. The intention of this proposal is not to subvert the regulation, but to comply with the spirit of it. Which is that the app should only work in browsers that can comply with the rules defined to protect eID integrations. You have two ways to achieve that: A) remove unsafe-eval, unsafe-inline and co. entirely (and we know how that goes on complex apps), or B) use controlled evaluations. Unfortunately, option B is not possible today without sniffing the UA when serving the HTML (and we know how that goes as well).
2. A prior art to consider is strict-dynamic, which does not require unsafe-inline to be present (and if it present, it will be ignored), as a mechanism to prevent arbitrary injections via HTML parsing mechanism while still allowing controlled injection of scripts via javascript.
3. With respect to your concern about misusing the "default" policy, even if that's the case, fortunately we have layering there, and it is not only that "default" to be enabled (via the CSP header), but you must also have "allow-duplicates" or create a protocol to share the default policy object with arbitrary code that is "allowed" to run in the page. I don't think that's what the regulation is attempting to prevent, IMO they are focused on XSS and any arbitrary injection from malicious actors while the application's code is considered trusted. We cannot see the removal of unsafe-eval in isolation as part of the eID regulation, it is a lot more than that.

I hope that this helps to clarify the relationship between this proposal and the eID regulations. We are looking forward to see @sysrqb and @johnwilander feedback on this issue.

from standards-positions.

In some discussion today at Web Engines Hackfest strict-dynamic came up as well. I believe strict-dynamic is the recommended way of using CSP these days so given that I wonder why we would add a feature that is redundant with it.

from standards-positions.

@annevk it is my understanding that they are complementary to each other. strict-dynamic by itself is not enough since it only protects from parsing-related injections. Plus, you're still at risk from Non-Script-Based XSS, DOM Clobbering, etc. TT can complement it by adding additional parsing (sanitizer), plus it can add additional restrictions to control who can evaluate code via script insertion or eval. I can only speak about our codebase at salesforce, which is significant, and all I can say is strict-dynamic is not enough for us at Salesforce, we need/want more fine controls.

from standards-positions.

I'm not disputing you don't want strict-dynamic and Trusted Types at the same time. But strict-dynamic obsoletes unsafe-eval. Thus I'm disputing the need for a variant of that.

from standards-positions.

@annevk I might be missing something important here. I don't understand how strict-dynamic obsoletes unsafe-eval. It has no implications on eval() or Function() constructor programatic invocations as far as I can tell, it only cares about parsed evaluations.

In theory, if you have a path forward to only evaluate trusted code (via strict-dynamic), then what's the risk? In practice, that's a lot harder to achieve, because trusted code might need to do funky stuff, specially for large systems with a lot of moving parts and legacy pieces (enterprise software is full of that), and the only way to use that is by eval some string, what would you do in this case?

One of the premises of TT is that it helps to pave the way to a better security posture by slowly closing more and more avenues. At least that's my understanding from the original discussions with Mike Samuels many years ago at the SES Meetings.

from standards-positions.