[wp-trac] [WordPress Trac] #52506: Add escaping method for table names in SQL queries

WordPress Trac noreply at wordpress.org
Mon Jan 10 00:38:41 UTC 2022

#52506: Add escaping method for table names in SQL queries
 Reporter:  tellyworth                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback has-patch has-unit-     |     Focuses:
  tests                                          |

Comment (by craigfrancis):

 As requested by Tonya (@hellofromtonya)...

 I've split [https://github.com/WordPress/wordpress-develop/pull/2127 my
 patch] so we can discuss Identifiers (table/field names) separately to the
 `IN()` operator.

 There should be no conflicts with printf(), as
 [https://en.wikipedia.org/wiki/Printf_format_string#Type_field printf()
 Types] have historically used both `%d` and `%i` for signed integers (it's
 `scanf()` that treats them differently), whereas
 [https://www.php.net/manual/en/function.printf.php PHP printf] only uses
 `%d`, allowing us to use `%i` for Identifiers.

 I've done my own performance tests, and generally find it about the same
 (nearly always a bit faster), this is due to one less RegEx, and with
 `%d`/`%f` using intval()/floatval() rather than escaping. But I'll see if
 I can get someone else (independent) to confirm.

 Security testing, I come from a security background, so I won't lie and
 simply say this is perfectly secure, because you cannot prove security
 (you can only prove insecurity), and because of the "%s / %5s" oddity (for
 legacy reasons the second value is not quoted); what I can say is that all
 user values will continue to be passed though
 intval/floatval/_real_escape, or it's this new Identifier (e.g.
 table/field names) where values are always backtick quoted and only allow
 "a-z", "A-Z", "0-9", "_" and "-" characters (this could be relaxed, but I
 thought I should start with the most restrictive set of characters that I
 am completely sure are safe).

 The addition of `$wbdp->version = 2` is not needed, but it might help
 address a concern raised by @johnbillion, so plugins can easily "determine
 whether it's able to use the new formats" (i.e. someone could have a
 `content/db.php` that provides their own `prepare()` method).

 I've added some basic unit tests (suggestions welcome for new ones); they
 check it accepts table/field names normally, invalid characters are
 removed, and the value is always/consistently quoted (this won't have that
 legacy quoting issue, and we shouldn't be doing weird things like
 removing/replacing quotes from the format string).

Ticket URL: <https://core.trac.wordpress.org/ticket/52506#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list