-
-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove esc_url()
and esc_url_raw()
from list of escaping functions
#2241
Comments
How would we then escape an URL?
|
@smileBeda In this case, no escaping is involved since nothing is being printed. In your case, I'm only raising the issue for |
I appreciate the intent of this issue, but currently disagree. As far as I can see, all escaping functions are passed through a filter prior to returning, so there's always the possibility that a plugin or theme is returning unescaped output by filtering the return value. If WP core wants to avoid this, we'd need to add some validation and cleanup to the filtered value or deprecate and remove the filters entirely. |
I agree with @joemcgill and from a security perspective would be very much in favour of removing filters from these type of escaping functions. Unfortunately, I doubt such a change would be accepted in WP as it would be regarded as a BC break. |
Is your feature request related to a problem?
Consider the following code (similar to what is found in core's
WP_Scripts::do_item()
method:Looks good, right? (Ignoring
WordPress.WP.EnqueuedResources.NonEnqueuedScript
.) Actually, no. It turns out that plugins have been abusingesc_url()
here to inject additional attributes. For example, WP Engine includes the following snippet in their article How To Defer Parsing of JavaScript in WordPress:It turns out that before
esc_url()
function returns, it passes its return value through aclean_url
filter. Plugins can take this filter and, assuming the context that the URL is going to be output in (including single- vs double-quoted attributes), and it can manipulate the value to introduce new attributes on the tag. Such hacks should not be allowed, as they are terribly brittle (and plain terrible).This came up recently as well for the
admin_body_class
filter (Core-58336) where the lack ofesc_attr()
allows for additional attributes to be added to thebody
(as well as potential security vulnerabilities). I recall this was also a hack that used to be employed to add attributes to thebody
tag, by (ab)using thebody_class
filter (as well as adding attributes todiv.post
wrappers viapost_class
filter) which was stopped three years ago in Core-20009. See WordPress/wordpress-develop@d17a57a.Describe the solution you'd like
Given that attribute injection hacks involving
post_class
,body_class
, and (soon)admin_body_class
were all put an end to in core, I think WPCS should perhaps consider doing the same for cases involvingesc_url()
. This can be achieved by removingesc_url()
andesc_url_raw()
from the list of escaping functions.Therefore, the above snippet would need to be rewritten as in order to pass the
WordPress.Security.EscapeOutput
sniff:I suggest to remove these lines or set them to
false
:WordPress-Coding-Standards/WordPress/Sniff.php
Lines 63 to 64 in fca9d9e
The text was updated successfully, but these errors were encountered: