[wp-trac] [WordPress Trac] #27421: Escape madness in meta API

WordPress Trac noreply at wordpress.org
Sat Mar 15 16:20:51 UTC 2014


#27421: Escape madness in meta API
--------------------------------+-----------------------------
 Reporter:  Denis-de-Bernardy   |      Owner:
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Options, Meta APIs  |    Version:  3.8.1
 Severity:  normal              |   Keywords:
  Focuses:                      |
--------------------------------+-----------------------------
 I was trying to come up with a reasonably sane wrapper around the WP meta
 API so as to no longer need to call it directly, and I'm somewhat bemused
 by the slashing insanity in there...

 As I read through the code:

 - get_post_meta() expects key and value to be unslashed
 - add_post_meta(), update_post_meta() and delete_post_meta() expect key
 and value to be slashed
 - WP uses wp_unslash() to strip slashes in add_metadata(),
 update_metadata(), and delete_metadata()
 - the codex suggests to use wp_slash() to add slashes before storing data

 This could all work in the best of worlds, but then:

 1. the codex is mysteriously silent on the need to slash keys as well
 2. wp_unslash() will dutifully unslash objects, but wp_slash() doesn't
 slash them to begin with
 3. wp_slash() and wp_unslash() would not be able to slash private
 variables (short of using Reflection, perhaps) even if they wanted to
 4. wp_slash() and wp_unslash() will not bother processing array keys that
 could have been sent from e.g. a POST request.

 Admittedly, it's not every day where $_REQUEST keys are inserted as is the
 database, so there's likely little room for SQL injections with respect to
 that last point, and array keys are typically without slashes, leaving
 little room for quirky keys that lose their slashes while getting stored.

 Still, I'm left scratching my head as to if/when we'll actually allow
 objects to get stored using the meta API without running the risk of
 seeing their data unslashed at arbitrary points in time.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27421>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list