Opened 10 years ago
Last modified 5 years ago
#30036 new defect (bug)
Add some escaping to $handle when printing styles.
Reported by: | georgestephanis | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Script Loader | Keywords: | needs-patch |
Focuses: | Cc: |
Description
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.
Attachments (1)
Change History (4)
#2
@
10 years ago
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.
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".