2024 Trusted Types and The Sanitizer API

WEH 2024 - Trusted Types and The Sanitizer API

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/32

Notes

Luke: This is what I've been working on at Igalia - it's a spec to give limited trust access to mechanisms that would normally enable XSS. There is the trusted objects themselves and there is a default fallback policy. You opt in through a CSP directive, that will set up enforcement. It allows you to create a policy, those policies are trusted objects - they're a function that you can use to determine how it is trusted - like trustedTypes.createPolicy("foo", createHTML(value) => DOMPurify.sanitize(value)) - there is also a default policy (a policy called "default") and it will call that automatically..

You can also create/send violation reports with metadata which you can send to an endpoint.

Why Trusted Types: There's currently no platform santizer API, and there are many sinks. Trusted Types can help make sure those sinks are kind of monitored and used respnsibly. Google has rolled this out to many properties, XSS reports 30% went down to 4%.

Current status: Chrome released it about 4 years ago, it's currently in progress implementations in WebKit and Firefox (Igalia is doing the work).

{Luke shows the (long) list of sinks for HTML, Script and ScriptURL.}

Looking forward to the future there are ideas on adding a fromLiteral tagged template (without interoplation) to identify a static string that you deem is safe

Also a new keywords for trusted-script-eval (or some name) which is similar to unsafe eval, but is enforced by older browsers and allows some changes to where reviews need to happen, and add at least some control

And, ultimately, a builtin sanitizer API - new function pairs that are like setHTMLUnsafe parseHTMLUnsafe along with sanitization options. The new safe functions won't require a trusted type object because they are safe by default.

limits on the violation url - localhost is dodgy.

-- does this require strict mode? Luke: that's a good question, idk actually

-- this was the thing that convinced me that js was wonderful and terrible, you can read the info from your callers

Luke: It's a good question, I'll check into it.

-- Does it also sanitize tag like, links, or forms

Luke: If there it is a JavaScript URL - so if it is javascript: yes, but if it is script navigation or other URLs, it's not. Some of those things can be protected by other CSP mechanisms.

Jonathan Kingston: I wondering if the specwork has been completed for integration into HTML and DOM - and like, if it works on setAttribute, is it only in cases when a script is manipulated

Luke: The spec had a bunch of issues when we picked up - it was patching a lot of specs, we've done a lot to clean that up, things that have been merged upstream - in the DOM, there are several. One of the big things TT does introduce is places where it can add algorithm steps where previously there weren't. One of the big things that happned with our work is that some sinks were enfoced via attributes, they were IDL - but there were conditional cases. We've been taking care to make sure exceptions were in the same order and interoperable and mitigating compat risks. originally eval() was able to transform - it can in theory change the script - except the mechanics didn't allow that. There's been specwork - it should be quite a bit better, it's not quite finished.

Jonathan: Are there concerns you didn't catch them all? There were concerns that if you didn't catch them all then later switch it on you break a lot of the internet

Luke: If there is a HTML parser sink we've been moving it upstream it should live in HTML and we should be able to capture that. There is a potential risk with new things being added, we had to make sure with setHTMLUnsafe - there were some that were protected that just aren't anymore - stuff that had to do with flash, for example, are no longer a risk.

Nicolo: eval is the only sink that doesn't support sanitizing - maybe that would actually be useful for polyfilling compilers?

Luke: eval specifically - that restriction came from tc39 sanitization, namely because it's hard to get it into the right path - the eval or the function constructor - there's been pushback about some of these being able to change the script partway through

Anne: Can you say more abou that discussion?

Nicolo: I was the one that channeled the feedback from tc39 - it's just that changing eval is considered scary in the community. I was the one suggesting the least resistence path, just get it through without trouble because there was no example of how you could do that in a safe way.

Luke: But then there was discussion with google security and salesforce - if that was something that was needed, and as you asked: How do you sanitize script - one way is to have an allow list, or something with a policy.. the utility of being able to change the script wasn't immediately obvious. It is something we could revist in the future. Currently we can't allow it. Implementationwise it does make it simpler

anne: Were there a lot of community members that feel this way? It seems ok but also I would rather it not be there, we don't have it for any other places. I can see maybe cases where you could mitigate some known dangerous thing with a proxy thing or something... It doesn't seem like we would want to block that

Nicolo: There wasn't specific pushback, we didn't even propose it - the pushback is from previous discussions

anne: I'm not even saying there are use cases, I'm just saying I don't know why we introduce the inconsistency and why we have the second step if it isn't needed. At least we should document somewhere why

Dan: Does trusted script eval make any sense at all - the dynamic strings

Luke: Currently you need unsafe-eval csp directive with trusted types - in browsers that support trusted types, that's ok. But in older browser that don't support it it will just eval -- this would protect the older browsers case. Salesforce, for example has this ShadowRealms like architecture ...

Dan: Given this connection with ShadownReals, maybe we could unblock this -- if we had that, I believe that you would just do a module import or something - there is this dynamic-script mode - it's more restricted than eval, but it is really close

Nicolo: Is it just like saying you could use dyamic import?

Dan Yes

Nicolo: So how is it different

Dan/Luke explaining one is taking place in the global and the other is in ShadowRealm, so this can guarantee CSP's real promises. That should help limit the scope of what can be evaluated. The reason that is stalled is this discussion around what should be exposed to the global. I had proposed it maybe would be things that touch I/O - things that are at the intersection of all of the platforms. Anne?

Anne: I am a little confused - originally we were talking about trusted-script-eval - I'm not sure how we got here.

(Luke attempts to explain how we got there)

Anne: So currently if you eval in a shadow realm is it governed by policies we have?

Nicolo: It is in theory, but it isn't in specs. Shadow Realms isn't a "proper security boundary" - they inherit a bunch of stufff

Anne: So how is it different

Luke: I think just that you can use importValue

Dan: Because we have this mechanism in ShadowRealms that is better than this trusted policy thing.

Anne: What we are comparing is kind of eval in a document setting vs a shadow realm that does imports - you wouldn't have to use unsafe eval or trusted script eval.

Luke: A shadow realm polyfill is still going to eval

Anne: They could just proxy the script - fetch a url from your own domain, but it's async.

Dan: I guess strict-dynamic is the current best practice, it's trying to protect from markup injection.

Jonathan: Why are you dealing with this older browsers case instead of just using a header/sending different content or something

Luke: That's a pretty big ask for something as big or complex as Salesforce

Nicolo: With this keyword you could still serve the same code with allow/disallow?

Anne: I have heard strict dynamic is what everyone recommends too... ?missed? If that is the recommended thing going forward, I'm not sure we need this in particular because it seems like unsafe eval is already ignored. I think we should try to have a good answer to that.

Nicolo: We have been focusing on the salesforce use case but google has also heavily deployed this - do we know if strict dynamic/shadow realms helps?

Luke: I don't think they have eval in there like that, meta is rolling it out - I have some use on my website - it's relatively easy to setup in CSP. One thing that is challenging is that you can't do reporting via only meta tag - you have to have control over the server -- and you're not just running localhost

Nicolo: Another topic - is there any thought about how this works with frameworks?

Luke: Vue is integrating this. They already handle the sanitization and whatnot. They create a vue policy and you can just allow that as a CSP and that will work. With regards to react I am guessing it is similar to setDangerously -

Nicolo: I was thinking about all of these things with their syntax where it looks like you set an attribute statically but then it is dynamically set.

Luke: I think angular is done/works just like vue if I remember correctly. Lit also supports trusted types. fromLiteral would probably be useful for them. I think the thing with other browser changing their positions has helped it move a lot forward

Johnathan: Sanitizer API - what's happening

Luke: It shipped it chrome, it unshipped in chrome, it's changing.. I know that both FF and chrome have people interested and some implementation ... It's going to be a similar idea of trying to block cross site scripting - the common. MathML for example has some challenges with href..

My understanding is that the safe would be a baseline you could make more safe, but not less safe.

Anne: It's still a bit of a design challenge - how exactly do we want people to adjust the policy - what do we want people to allow to send/what is the default. There have been proposals all over the place. Where exactly we wind up is not exactly decided.

Luke: If you have a site with script gadgets you want, are you even going to enable this? As with trusted types there are things you can still do which are unsafe - the idea with trusted types be 'your code is trusted' - preventing XSS rather than mitigating what it can do.