问题描述
我的公司想在他们的网站上使用 WordPress，我主要关心的是使用准备好的语句.根据this，我难以置信地自己阅读了源代码，WordPress 会清理字符串，但不是 在数据库中准备.
My company wants to use WordPress for their Internet site and my main concern is the use of prepared statements. According to this, and I read the source code myself in disbelief, WordPress sanitizes string but is not prepared at the database.
我能做些什么来获得真实的东西吗?还是我的担忧毫无根据?
Is there anything I can do to get the real thing? Or are my concerns unfounded?
推荐答案
历史
了解 wpdb 类，最初是 一个分支 Justin Vincent 的 ezSQL 库，引入了 早在 2003 年，只有 几个月后 MySQL 准备语句协议发布并且超过 一年前 PHP 有任何 API 支持来访问它:因此 WordPress 做了它当时唯一能做的事情，并且需要将任何变量直接连接到动态 SQL 中.
History
Understand that the wpdb class, originally a fork of Justin Vincent's ezSQL library, was introduced way back in 2003, only a couple of months after the MySQL prepared statement protocol was released and more than a year before PHP had any API support for accessing it: WordPress thus did the only thing it then could, and required any variables to be concatenated directly into dynamic SQL.
那时，ezSQL(以及 WordPress)使用 PHP 的mysql_escape_string() 函数来转义此类文字，因此不知道数据库连接的实际编码(这种威胁仅在 PHP 本身中得到解决就在几个月前).
Back then, ezSQL (and thus WordPress) used PHP's mysql_escape_string() function to escape such literals—and were therefore ignorant of the database connection's actual encoding (a threat that had only been addressed in PHP itself just a few months earlier).
这仍然是 WordPress(唯一)针对 SQL 注入的防御近两年，因此改用(安全性更低)addslashes() 用于转义——然后这种情况仍然存在 四年多，直到 mysql_real_escape_string() 终于已使用(尽管wpdb::prepare() 已引入在临时)！
This remained WordPress's (only) defence against SQL injection for nearly two years, whereupon it switched to using (the even less safe) addslashes() for escaping—a situation that then remained in place for over four years until mysql_real_escape_string() was finally utilised (albeit wpdb::prepare() had been introduced in the interim)!
然后是又五年，直到WordPress 甚至开始使用一个能够本地语句准备的驱动程序(即 MySQLi):现在不到两年前，正如@naththedeveloper 已经指出，ticket #21663 中的讨论表明，使用本机准备好的语句甚至可能不会列在待办事项清单上.
It then wasn't for another five years until WordPress even began using a driver capable of native statement preparation (i.e. MySQLi): this now just under two years ago and, as @naththedeveloper already pointed out, the discussion in ticket #21663 suggests that using native prepared statements may not even be on a to-do list.
不幸的是，由于 MySQLi 对象是 wpdb 类的受保护成员，没有 getter(并在内部分配了 在实例化期间)，没有办法您可以将原生准备好的语句与 WordPress 的数据库连接一起使用(至少，不能不使用您自己的类修改/替换 wpdb).
Unfortunately, since the MySQLi object is a protected member of the wpdb class for which there's no getter (and is assigned internally during instantiation), there's no way that you can use native prepared statements with WordPress's database connection (at least, not without modifying/replacing wpdb with your own class).
我能做些什么来获得真实的东西吗?
当然，您可以打开自己的/单独的数据库连接，您可以完全灵活地按照自己的意愿进行操作.
You can, of course, open your own/separate connection to the database over which you have complete flexibility to do as you wish.
或者我的担心是没有根据的?
与原生语句准备一样出色(我同意它确实应该成为任何新项目中针对 SQL 注入的默认防御策略)，它还具有 它的缺点.小心地转义用作 SQL 文字的变量(例如，由 PDO 的准备语句模拟完成；这就是 wpdb::prepare() 这些天试图提供的内容)应该 抵抗所有已知的攻击...
As great as native statement preparation is (and I agree that it really should be the default defence strategy against SQL injection in any new project), it does also have its downsides. Careful escaping of one's variables for use as SQL literals (as done by PDO's prepared statement emulation, for example; and which is what wpdb::prepare() these days attempts to deliver) should be resistant to all known attacks...
这篇关于我该怎么做才能在 Wordpress 中获得实际准备好的语句的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！