[wp-trac] [WordPress Trac] #32937: $wp_query->parse_orderby() allows incorrect keys to go through(edge case)
WordPress Trac
noreply at wordpress.org
Thu Jul 9 10:18:26 UTC 2015
#32937: $wp_query->parse_orderby() allows incorrect keys to go through(edge case)
--------------------------+-----------------------------
Reporter: nikolov.tmw | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Query | Version:
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
This is similar to #24674, in the sense that it's related to the quirks of
non-strict `in_array()` checks.
Here's what I think is needed to reproduce the problem:
- Use a `$table_prefix` that starts with a number(my case was `1..._`)
- Do a query that uses multiple meta queries
This results in the `$allowed_keys`(in query.php, the `parse_orderby()`
function) looking like this:
{{{
array(24) {
...
[18]=>
string(6) "_price"
[19]=>
string(10) "meta_value"
[20]=>
string(14) "meta_value_num"
[21]=>
string(16) "1..._postmeta"
[22]=>
string(3) "mt1"
[23]=>
int(1)
}
}}}
I do have to mention that this was triggered by (in my opinion) incorrect
usage by WooCommerce - they are setting the orderby clause to
`"meta_value_num {$wpdb->posts}.ID"`, which would go through(because it
starts with 1 and item 23 in the array is `int(1)`) and then gets escaped
to `post_1..._postsid`, which in turn would break the query, since there
is no such column.
However, despite the incorrect orderby parameter, I think that we should
use strict checking for this `in_array()` call in order to prevent keys
that are not really valid to go through.
In case you were wondering where the `int(1)` in the end comes from, it's
one of the keys of the `$meta_clauses` array - they get merged into the
`$allowed_keys` array.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/32937>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list