Add support for JavaScript templates (Underscore) to wp_kses()

[stevegrunwell]

When working with Backbone/Underscore templates, wp_kses() will mangle placeholders like <%, <%=, and <%-.

Example:

$string = '<div id="post-<%- ID %>"><%= title %></div>';
$allowed_tags = array(
  'div' => array(
    'id' => true
  )
);
$result = wp_kses( $string, $allowed_tags );

My expected result would be the same as $string:

<div id="post-<%- ID %>"><%= title %></div>

However, the actual result is mangled:

&lt;div id=&quot;post-"&gt;</div>

Use-case for this enhancement:

Ajax-powered widgets and blocks (including those used within WordPress core) that want to offer filters for developers to use while safely escaping the potentially-filtered HTML of the templates before printing them to the screen.

[stevegrunwell]

Adds new wp_kses_template() function (separate function since this is only needed in certain circumstances) that will automatically replace Underscore template tags with placeholders before running wp_kses(), then restores them afterwards.

[dd32]

I'm not sure I see the need for kses to handle such data myself.

Kses is designed to be used to strip invalid/unsafe HTML code from a user-supplied string, and does a pretty good job at that.

Any templates should be hard-coded by a developer, either within their plugin, or allowing another plugin to filter the HTML, there's no real need to kses the HTML in those cases as it's not coming from an untrusted user.

Kses is an expensive function call, it should be called as rarely as possible, for WordPress posts that means it's called on save, and shouldn't be called on display.

[stevegrunwell]

@dd32, that's a very good point - the instances where JavaScript templates should be user provided (without at least requiring some extra work on the part of the developer) is slim to nil (hence why I wrote this as a separate function rather than build it into the main wp_kses()). Even if third-party plugins are able to filter templates and thus potentially make them evil before they're displayed, that would be the result of a third-party plugin that the user has installed on his/her WordPress site.

The behavior of wp_kses() still seems broken when it's handed an Underscore template, however. Do you think a simple str_replace() for Underscore template tags (<%, <%=, <%-, and %>, probably including trailing/leading spaces on opening/closing tags, respectively, but I would need to confirm with the Underscore parser rules on spacing) would suffice? Using the example in the original ticket, the expected output would then be a harmless <div id="post-ID">title</div>, which should prevent any parsers from breaking.

[miqrogroove]

I agree with dd32. wp_kses is working as intended in this situation.

[dd32]

The behavior of wp_kses() still seems broken when it's handed an Underscore template, however.

In my opinion it's working as intended, as Underscore template tags are not HTML, it's strippping/sanitizing unexpected/malfomed HTML from the string.

[stevegrunwell]

With the impending release of the JSON REST API, there will likely need to be more attention paid to providing a proper template sanitization method for JavaScript templates. If KSES isn't the route, that's fine - I have faith in the core team's direction :).

[nacin]

Aside from a separation of concerns issue that's been hashed out here already, the other issue is that Underscore templates are, by their very nature, JavaScript. They're insecure. Allowing them to be included would allow JavaScript to be executed in potentially unintended ways.

[swissspidy]

#62025 was marked as a duplicate.