Skip to content
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

XSS sniff: improvements for printing function list #315

Merged

Conversation

JDGrimes
Copy link
Contributor

Several improvements for the list of printing functions in the XSS sniff.

  • Removes non-printing functions from this list.
  • Renames the property to clarify what it is for.
  • Allow custom printing functions to added via XML config.

This list was added in 722b2c6, as
part of work on WordPress#33. The intention was to properly handle functions
like `_e()` which generate direct output. However, for some reason we
went overboard and added a bunch of l10n functions, most of which do
not print output.

I’m removing these non-printing functions.
After ff82f06, this clarifies the
intent of this list.
We already do this with the lists of sanitizing and auto-escaped
functions.
This has be `@todone`!
westonruter added a commit that referenced this pull request Feb 19, 2015
…funcs

XSS sniff: improvements for printing function list
@westonruter westonruter merged commit 11e541b into WordPress:develop Feb 19, 2015
@JDGrimes JDGrimes deleted the bug/xss-not-needs-sanitization-funcs branch February 19, 2015 14:59
JDGrimes added a commit that referenced this pull request Apr 15, 2015
In #33, a list of localization functions like these were flagged as
needing escaping. In #315 I amended this list, removing non-printing
localization functions like `__()`, among other things. These changes
caused a regression in the treatment of the `_e()` and `_ex()`
functions, which remained on the list. They were previously flagged as
needing escaping, even when their parameters were “safe” values
(encapsed strings). That behavior was intentional, and was added
because these functions incorporate other values into their final
output, which need to be escaped before being printed. After #315,
however, these functions themselves were not flagged, only their
parameters when deemed unsafe (e.g., `_e( $var )`). This restores the
previous behavior, by classifying these as ‘unsafe printing functions’,
and flagging them as such when they are used.

For performance, I’ve opted to skip checking the parameters of these
functions when they are flagged, since the recommended replacements
will remedy any issues there as well. If the error for the function
itself is disabled though, any non-safe values incorporated into the
parameters will still be flagged.
@GaryJones GaryJones added this to the 0.4.0 milestone Aug 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants