[wp-trac] [WordPress Trac] #56701: Sanitize HTML Classes added to single row columns in WP_List_Table

[WordPress Trac]

#56701: Sanitize HTML Classes added to single row columns in WP_List_Table
-------------------------------------------------+-------------------------
 Reporter:  bananastalktome                      |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.1.1
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing 2nd-opinion  |     Focuses:
                                                 |  administration
-------------------------------------------------+-------------------------
Changes (by azaozz):

 * keywords:  has-patch needs-testing => has-patch needs-testing 2nd-opinion


Comment:

 Replying to [comment:7 Clorith]:

 > Normally, what we want to do is sanitize anything that is saved, and
 escape when outputting it

 Right. This applies for strings that are typed by a user. So the question
 here is: can a user add HTML classnames there? That doesn't seem possible
 in core. Seems only plugins can, and the classname(s) are most likely not
 saved in the DB (so they can be sanitized on saving), but hard-coded in
 the plugin.

 Agree with @costdev's
 [https://wordpress.slack.com/archives/C02RQBWTW/p1667607331088069?thread_ts=1667570082.715479&cid=C02RQBWTW
 comment on Slack] that this is similar to #56655. In both cases the
 strings can only come from trusted source (plugins and themes) and are
 likely hard-coded. No point to sanitize them (if there is malicious
 code/intent, it can do a lot more harm in many other places).

 > in this case, we should instead of relying on sanitize functions, use an
 escaping function either in the `echo` portion of the code...

 Frankly I'm not even sure that escaping is needed here. There is no point
 to escape hard-coded classnames, right? The only difference here seems to
 be to "catch" plugins that misuse the filter(s) to break out of the
 current tag and add arbitrarily HTML. In that case a `_doing_it_wrong()`
 would probably be better?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56701#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform