Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer Failure when receiving data from the peer 从对等方接收数据时失败 当WordPress 4.8.2发布时，它包含了针对上述问题的补丁。该补丁完全包含在WPDB: prepare（）中，补丁只添加了1行代码： $ query =  preg_replace（ '/％（？％| $ |（[^ dsF]））/'， '%% \\ 1'，  $ query ）; 这行代码做了两件事。 1是删除除％d，％s，％F之外的sprintf令牌，因为该漏洞依赖于％c，从而使漏洞无效。 2是删除位置替换的能力，即％1 $ s等参数无效。 这引起了开发人员的不满，因为WordPress在官方文档中说只能使用％d，％s，％F。即使官方文档是以这种方式编写的，数百万个第三方查询代码也使用以前的语法规则。 WordPress以“不会修复，抱歉”回复并拒绝提供有关安全性的更多详细信息。 升级到最新版本 该漏洞是将用户输入传递给prepare的服务器。最初的漏洞POC是这样的，安全查询代码如下： $ db-＆gt; prepare（'SELECT  *  FROM  foo  WHERE  name= '％4s'  AND  user_id = ％d'，  $ _GET ['name']，  get_current_user_id（）） ; 4.8.2的变化是％4s将被重写为%% 4s，这意味着％d将反弹回$ _GET ['name']，使攻击者有机会获得用户ID。这可用于权限提升攻击。 WordPress回应说：“谢谢，我们不支持”。 插件开发者应该？ 然后，作者设计了一个不同的POC，使用另一个重要事实来证明漏洞不是％1 $ s，而是将用户输入传递给准备查询。 Meta.php文件代码如下： 如果 （  $ delete_all ）  {    $ value_clause = '';    if （ '' ！==  $ meta_value ＆amp;＆amp;  null ！==  $ meta_value ＆amp;＆amp;  false ！==  $ meta_value ）  {      $ value_clause =  $ wpdb-＆gt; prepare（ '  AND  meta_value = ％s'，  $ meta_value ）;   }    $ object_ids =  $ wpdb-＆gt; get_col（  $ wpdb-＆gt; prepare（ 'SELECT  $ type_column  FROM  $ table  WHERE  meta_key = ％s  $ value_clause'，  $ meta_key ）   ）;} 输入： $ meta_value = ' ％s '; $ meta_key =  ['dump'， '  OR  1=1 /*']; 生成以下查询： SELECT  type  FROM  table  WHERE  meta_key = 'stump'  AND  meta_value = ''  OR  1=1 /*' 核心文件已成功注入，$ meta_value和$ meta_key都来自用户的输入。将产生以下赋值条款： AND  meta_value = ' ％s ' 未引用的％s由prepare引用的％替换，第二次调用 - > prepare（）将子句转换为AND meta_value=''％s'并且可以注入。 作者指出，该漏洞无法在WPDB: prepare（）中修复，但是在meta.php中存在问题。可以通过阻止双重准备调用来缓解此漏洞。但是，原始漏洞无法修复。 漏洞 简单补丁不会将用户输入的$ query参数传递给meta.php中的WPDB: prepare（）。将用户输入传递给$ query是错误的。 最早的补丁 下一步是在预查询中引用占位符，然后在执行查询之前恢复占位符。这个补丁已经存在。基本上，补丁将修改WPDB: prepare（）以用％占位符替换随机字数，例如： $ query =  str_replace（'％'， '{$ this-＆gt; placeholder_escape}'，  $ query ）; 然后，在WPDB:中，_do_query（）删除占位符以恢复原始用户的用户输入。 我仍然认为将用户输入传递给prepare的查询端是有潜在危险且不安全的。即使您解决了已知的安全漏洞，双重准备字符串也很危险，因为准备的结果会传递给另一个。 最初补丁的第一个问题 正确的补丁应该是放弃整个准备机制。像普通查询一样返回语句或查询对象，或直接执行查询。这样就可以防止双重准备字符串。值得一提的是，这将是WP的主要变化。其他平台都有成功的先例，例如PHPBB经历同样的事情，从大规模的SQL注入漏洞到几乎没有SQL注入漏洞。它不需要快速解决，可以与现有API并行处理，并慢慢替换旧的API。当前的系统在设计上并不安全，但并不意味着它会经常被黑客攻击，但你应该尽量避免被黑客攻击。最好使用默认的安全设计，并使不安全的特殊情况。最佳实践是使用PDO/MySQLi和实际准备好的语句。这些变化并不能防止滥用，但会使滥用变得更加困难。 https://blog.ircmaxell.com/2017/10/disclosure-wordpress-wpdb-sql-injection-technical.html