SQL Injection caused by improper ThinkPHP patch repair

SQL Injection caused by improper ThinkPHP patch repair

This is ThinkPHP patch for this injection: https://github.com/liu21st/thinkphp/commit/23c6e130ce75f2132e5b48699363a75ed28e15b2

 

}elseif(is_array($val) && isset($_REQUEST[$key]) && is_array($_REQUEST[$key])){$options['where'][$key]=(string)$val;

This logic ......

To put it simply, his logic is: $ key is the database field name, and $ val is the input parameter.

When $ val is an array and $ _ REQUEST [$ key] exists and $ _ REQUEST [$ key] is an array, the $ val parameter I passed in is forcibly converted to a string.

However, is the $ _ REQUEST [$ key] directly related to the $ val I passed in?

For example
 

$map['username'] = $_POST['name'];M('user')->where($map)->find();

At this time, $ key is username, but I actually passed in $ _ POST ['name'], which is name. Did thinkphp developers confuse two "keys? Is it misled by the onethink example I found?



I am not looking for an instance. Let's take a simple example.

If the code is written like this (the key in the POST object is the same as the key in the database, it is all uname)
 

public function test(){$u = M('user')->where(array('uname' => I('post.uname', '', 'trim')))->find();dump($u);}

You can defend against this attack. You can see that:
 

However, if the two keys are different:
 

public function test(){$u = M('user')->where(array('uname' => I('post.name', '', 'trim')))->find();dump($u);}

Continue to inject:
 

 

Solution:

Enhanced Filtering