[wp-trac] [WordPress Trac] #40825: Re-addressing validation/sanitization of IDs to allow filtering before WP_Post (and others) database query

WordPress Trac noreply at wordpress.org
Mon May 22 17:52:44 UTC 2017


#40825: Re-addressing validation/sanitization of IDs to allow filtering before
WP_Post (and others) database query
-------------------------------+------------------------------------
 Reporter:  LindsayBSC         |       Owner:
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  4.7.5
 Severity:  normal             |  Resolution:
 Keywords:  dev-feedback       |     Focuses:  template, performance
-------------------------------+------------------------------------

Comment (by LindsayBSC):

 I have certainly thought about this and here are my thoughts on the
 security issue w/ regards to the filter:

 Since the purpose of filtering the ID number to allow for non-numeric ID
 numbers, we could actually create a wrapper function for the
 `is_valid_id()` function that is `get_is_valid_id()` which would be used
 only on 'read' requests for info and not any write requests. This means
 there would be no way to filter the ID value when using `wp_insert_post()`
 or `update_post_meta()` but for the purpose of displaying non-native
 content as if it were native content (ie: a post, user, term) we would
 still be able to filter the ID, making the filter much less dangerous and
 more like `the_content()` filter which is for output/display only.

 See an example here:
 You can see the wrapper function in get_is_valid_id.php and on line 7 and
 line 46 has the `get_is_valid_id()` and `is_valid_id()` respectively.

 https://gist.github.com/LinzardMac/ab4012d413b7f656c3dc7c80fc2f501f

 I know this is a bit rough, but it illustrates the concept. It may be able
 to be made even more efficient.

 Replying to [comment:3 peterwilsoncc]:
 > I've chatted a bit about this to @LindsayBSC in Slack.
 >
 > A unified approach to object ID validation appeals to me a great deal.
 There has been a lot of discussion about integers, BIG INTs and
 PHP_INT_MAX recently that highlights the need for something consistent
 that works across the board.
 >
 > I have hit situation where certain post types are hosted remotely with
 non-numeric IDs, so can see a use case for the filter. I have significant
 concerns about the security implications here as it would only take a
 small typo to create big problems. Core would need to defend against this.
 I'd like to see some thought into this defence.
 >
 > tl;dr: +1 on a validation function, in two minds about including the
 filter.

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


More information about the wp-trac mailing list