Add some escaping to $handle when printing styles.

[georgestephanis]

There's a number of instances where we're currently printing out the dependency handle without any sort of escaping. We should probably do something about that.

https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class.wp-styles.php#L87

WP_Styles::do_item()

Things can currently get somewhat mucked up if someone enqueues a script or style with a single quote in it, that breaks out of the id attribute.

I'm not sure what the best fix for this is, attached are some starting point unit tests to demonstrate the varied types of handles that work currently, that we'll want to at least take into consideration.

[azaozz]

Thinking we should be more restrictive. Don't see a good reason to support anything except [a-zA-Z0-9_-]+ for handles, both JS and CSS. To stay back-compat we can filter the handles on adding and using them, i.e. replace "unwanted" chars with dashes and throw "Doing it wrong".

[georgestephanis]

I'd be most comfortable if we used esc_attr() right before the output. That has the least chance for breakage on backward compatibility if someone's trying to call wp_style_add_data() on a funkily-named asset that had previously worked -- and now suddenly doesn't.

If we were building the system from scratch and didn't have to worry about backward compatibility, I'd probably also add one on when the dependency is registered/enqueued, but still as we do tend to work off of globals, would probably want the added security of esc_attr()'ing the output.

[westonruter]

It seems like this was half implemented.

We're using esc_attr() when ​printing an inline style:

<?php
$inline_style_tag = sprintf(
        "<style id='%s-inline-css'%s>\n%s\n</style>\n",
        esc_attr( $handle ),
        $this->type_attr,
        $inline_style
);

But not when ​printing the LINK tag:

<?php
$tag = sprintf(
        "<link rel='%s' id='%s-css'%s href='%s'%s media='%s' />\n",
        $rel,
        $handle,
        $title,
        $href,
        $this->type_attr,
        $media
);

The title attribute is getting escaped previously:

<?php
$title = isset( $obj->extra['title'] ) ? sprintf( " title='%s'", esc_attr( $obj->extra['title'] ) ) : '';

And $href is getting escaped because it is obtained by the _css_href() method which returns the value through esc_url().

Also, $media is getting passed through esc_attr() previously.

All of the escaping should be moved as late as possible when the LINK tag is being constructed.

This PR ensures that dependency handles used in id attributes (in both <script> and <link> tags) are properly escaped using esc_attr() in the following methods:

• WP_Styles::do_item()
• WP_Scripts::do_item()

[jonsurrell]

Leveraging the HTML API (and possibly an HTML templating solution like #60229) would be a nice change for situations like these. Escaping is handled contextually and correctly by the HTML API and no escaping should happen elsewhere:

<?php
$processor = new WP_HTML_Tag_Processor( '<style></style>' );
$processor->next_token();
$processor->set_attribute( 'id', 'foo' );
$processor->set_modifiable_text( '.class { color: red }' );
$inline_style_tag = $processor->get_updated_html();
echo $inline_style_tag;

// <style id="foo">.class { color: red }</style>

[SergeyBiryukov]

In 61084:

Script Loader: Consistently escape the style handle in WP_Styles::do_item().

Includes moving most of the escaping as late as possible when the <link> tag is being constructed.

Follow-up to [29956], [36550], [43564], [46164].

Props georgestephanis, westonruter, azaozz, jonsurrell, XecurAbhijeet, SergeyBiryukov.
See #30036.

Thanks for the PR! Merged in r61084.

It appears that the changes in WP_Scripts::do_item() are not necessary, as the value is already escaped on output via wp_sanitize_script_attributes().

@XecurAbhijeet To ensure your work is properly credited in WordPress releases, can you please ​link your Github and Wordpress.org accounts to ensure.

To understand the WordPress project's expectations around crediting contributors, please ​review the Contributor Attribution page in the Core Handbook.