Sanitized declarative patching

[Jamesernator]

It would be good to have a way to help prevent server side XSS while being able to delegate to the client side HTML sanitizer (which can presumed to be always up to date).

A couple ideas from another thread would be to have some attribute on <template>, i.e. something like:

<template for="marker" sethtml="UNTRUSTED_HTML"></template>

OR

<template for="marker" safe>UNTRUSTED_HTML</template>

As noted, the latter is still susceptible to template closing attacks e.g. UNTRUSTED_HTML="</template><script>doEvil()</script>". I'm not entirely sure of all the corner cases of HTML parsing, but I think the former is safe if we simply replace all quotes in UNTRUSTED_HTML with ".

To minimize risk further (e.g. missing attribute quotes), server environments could use tagged templates (or their language's equivalent, e.g. precompiled templates) to create sanitized patching locations, e.g. in JS this might look something like:

const untrustedHTML = `<script>doEvil()</script>`
const html = safeHTML`
    <p>${ untrustedHTML }</p>    
`;

gets transformed to:

<!-- Create a marker, immediately followed by a safe patch, the script is rejected by the sanitizer -->
<p><?marker id="UUID"?><template for="UUID" sethtml="&lt;script&gt;doEvil()&lt;/script&gt;"></template></p>

[noamr]

Interesting idea!

Regarding the shape,

I don't like so much the API of putting escaped HTML in an attribute, feels like HTML should remain uneacaped in an HTML doc....

I think a server can avoid the template closing attack by parsing the untrusted string into a fragment and re-serializing it, which is simpler than a whole script-aware sanitization.

But in both cases the client cannot guarantee the safety of this method and the string would need to go through some processing

[noamr]

Another idea that is perhaps safer is to use an src attribute for this, either on template or by a new script type, as mentioned in the explainer. Then to make it inline the src can be an escaped data URL but it's guaranteed not to exit the template.

I feel better about escaping when it's a data URL as it also covers the remote src use case nicely and escaping is more of a byproduct.

[Jamesernator]

I don't like so much the API of putting escaped HTML in an attribute, feels like HTML should remain uneacaped in an HTML doc....

We do already have precedence with this already with iframe's srcdoc.

Another idea that is perhaps safer is to use an src attribute for this, either on template or by a new script type, as mentioned in the explainer. Then to make it inline the src can be an escaped data URL but it's guaranteed not to exit the template.

I feel better about escaping when it's a data URL as it also covers the remote src use case nicely and escaping is more of a byproduct.

I like this approach too, I guess srcdoc vs src="data:..." on iframe has more to do with origins, so the same concerns probably don't apply here but it would be worth verifying this.

[noamr]

I was thinking about this today, and I believe that sanitization as well as client-sides includes can be completely separate from <template for>, but they could be made to work well together.

I will prepare an explainer about this in the next days/weeks, but my current thinking is that a client-side include would be a new script type, or rather two (safe and unsafe):

<script type="html" src="inline.html"> 
</script>

It can use a data URL for avoiding the fetch:

<script type="html" src="data:text/html,<some-markup>"> 
</script>

If using html rather than unsafehtml, it would sanitize the result,
so the following would strip away the inner script

<script type="html" src="untrusted.html"> 
</script>

We can perhaps support the inline version as well, and treat it as escaped, but perhaps that doesn't add much on top of data URLs.

If made safe in practice (which would have to go through a long way to answer), this can be a simple way to include external SVGs as inline SVGs?

As far as out-of-order streaming goes, those two features can be composed rarther than be a single feature:

<template for="marker">
   <script type=html src="data:text/html,UNTRUSTED_HTML"></script>
</template>

This would move the script into the placehollder where <?start name=marker> is, and then immediately replace it with the src.

(Just a thought atm)