模拟准备和直接准备调用之间的区别？答案

【问题标题】：The difference between emulated prepares and direct prepare calls?模拟准备和直接准备调用之间的区别？
【发布时间】：2013-03-14 23:17:07
【问题描述】：

数据库是否仍然容易受到使用prepare语句进行SQL注入的攻击，例如以下示例（我使用的是PDO和php 5.3版）：

  $unsafe = $_POST['user_input'];

  $stmt = $db->prepare("INSERT INTO table (column) VALUES ('" . $unsafe . "')");

这两个例子有什么值得一提的区别吗？

  $stmt = $db->prepare('SELECT * FROM table WHERE name = :name');

  $stmt->execute(array(':name' => $name));

和

    $stmt = $db->prepare('SELECT * FROM table WHERE name = :name');
    $stmt->bind_param(':name', $name);

    $stmt->execute();

方法执行中可以使用哪些类型的参数？

【问题讨论】：

PDO MySQL: Use PDO::ATTR_EMULATE_PREPARES or not? 的可能重复项

标签： php sql pdo prepared-statement sql-injection

【解决方案1】：

虽然不完全清楚你的实际问题是什么，但我还是这样说吧：

您发布的第一个 sn-p 已发布。根本没有一个有效的论据可以让您使用像mysql_* 这样的已弃用 扩展（或已弃用的扩展）。忘掉那些讨厌的mysql_connect 电话吧。
看看另外两个 sn-ps，我猜你正在使用 PDO，它确实支持准备仿真。事实上，它默认模拟prepare。但是，如果第三个 sn-p 是 mysqli_* sn-p，那么有什么问题？除非你运行的是 MySQL 3.x，否则你就可以了。

模拟准备和直接准备调用之间的区别在于，模拟可能会在不涉及 MySQL 服务器的情况下发现一些语法错误，因此效率更高。但是，如果您的 MySQL 服务器不支持准备好的语句，我很确定 PDO 会为您解决这个问题，所以您应该没问题。不过，不知道mysqli_*。考虑到所有因素，无论如何我都赞成第二个 sn-p。它的代码更少，与第三个 sn-p 做同样的事情，并允许整洁、易于维护的代码。

关于“方法执行中可以使用什么类型的参数”的问题，可以参考文档页面，PDO要么没有参数，要么是数组@987654321 @：bool PDOStatement::execute ([ array $input_parameters ] )
如果是mysqli_execute，则取决于您使用的是OO还是程序样式，as shown in the docs：
bool mysqli_stmt::execute ( void ) OO
bool mysqli_stmt_execute ( mysqli_stmt $stmt ) 程序样式

【讨论】：

进行了一些编辑以澄清一些事情（我首先复制/粘贴了 sn-p）。谢谢你的答案！

【解决方案2】：

数据库是否仍然容易受到使用prepare语句进行SQL注入的攻击，如下例所示

为什么？当然。因为在这个例子中没有实际使用准备好的语句。

模拟prepare和直接prepare调用的区别？

在安全性方面没有区别 - 任何一种方式都是安全的。
但是，可能会有如下所述的不便

Err... 我突然想到，您可能对 emulated prepares 有什么误解。
您问题中的第一个代码 sn-p 根本不是准备好的陈述，既不是模拟的也不是自然的 - 而是古老的良好推断，背后有所有危险。
虽然模拟准备只是代表 PDO 操作查询的方式，解释here

方法执行中可以使用哪些类型的参数？

这很明显 - 默认情况下，所有参数都被视为 strings。

因此，无论哪种方式，您的查询都是无懈可击的，但如果仿真打开，可能会带来一些不便 - 如果 LIMIT 子句中有占位符，您必须显式绑定参数，而不是将它们传递给执行，将 INT 类型设置为他们。
但是如果禁用了仿真，mysql可以对所有参数进行排序，并且可以将数组发送到execute()。

【讨论】：