WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#30967 closed defect (bug) (fixed)

$fallback in sanitize_html_class() is not sanitized

Reported by: mighty_mt Owned by: wonderboymusic
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.4
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

When looking at the source for the sanitize_html_class() function I just noticed that the $fallback variable is not being sanitized. Here's an example:

sanitize_html_class( "*!?", "This can't be valid!?" );

In this example the $class variable will be empty after sanitizing and the $fallback variable will be returned as is. So This can't be valid!? would be returned which is definitely not a valid CSS class.


I think that (if needed) the $fallback variable should equally be sanitized by either repeating the preg_replace calls or by recursively calling sanitize_html_class() passing $fallback as $class and leaving $fallback empty (while of course making sure to prevent infinite loops).
For performance reasons the first option might be better because any functions hooked to the sanitize_html_class filter would always be run only once.

Attachments (3)

30967.diff (609 bytes) - added by MikeHansenMe 6 years ago.
30967.2.diff (628 bytes) - added by MikeHansenMe 6 years ago.
check if fallback is already an empty string before sanitizing it
30967.3.diff (526 bytes) - added by wonderboymusic 6 years ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @MikeHansenMe
6 years ago

Looking at that function I find it a bit strange that there is even a fallback. The reason is by default if the sanitized text is an empty string it return a different variable that is also an empty string. It seems if someone puts in a fallback that also gets sanitized it could be an empty string as well. Not saying it shouldn't be sanitized, just seems strange. I could not find any places in core that use the fallback.

#2 in reply to: ↑ 1 ; follow-up: @mighty_mt
6 years ago

@MikeHansenMe: Sure the sanitized fallback might end up being empty too but I think that's better than returning an invalid CSS class name.

By the way, I just quickly did a full text search of all PHP files in the wp-incudes directory and found that there are a few places in core where the fallback is used... once in the get_comment_class() function and multiple times in get_post_class(). See also #30883.

#3 in reply to: ↑ 2 @MikeHansenMe
6 years ago

Replying to mighty_mt:

By the way, I just quickly did a full text search of all PHP files in the wp-incudes directory and found that there are a few places in core where the fallback is used... once in the get_comment_class() function and multiple times in get_post_class(). See also #30883.

Not sure how I missed those. Every use case was to use an id if the slug/nice_name could not be sanitized without being empty. I think sanitizing the fallback should probably happen either way.

@MikeHansenMe
6 years ago

@MikeHansenMe
6 years ago

check if fallback is already an empty string before sanitizing it

#4 @MikeHansenMe
6 years ago

  • Keywords has-patch added

#5 @DrewAPicture
6 years ago

  • Version trunk deleted

#6 @wonderboymusic
6 years ago

  • Milestone changed from Awaiting Review to 4.4
  • Version set to trunk

what is recursion? 30967.3.diff

#7 @wonderboymusic
6 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 34377:

Sanitization: when falling back to (wait for it...) $fallback in sanitize_html_class(), sanitize it as well.

Props MikeHansenMe, wonderboymusic.
Fixes #30967.

Note: See TracTickets for help on using tickets.