此 PDO 代码如何防止 SQL 注入？答案

【问题标题】：How does this PDO Code protect from SQL Injections?此 PDO 代码如何防止 SQL 注入？
【发布时间】：2011-10-18 09:58:43
【问题描述】：

所以我正在研究整个 PDO 的事情，当我遇到这段代码时，我正在阅读这篇博客教程，解释是如果我将 PDO 与数据绑定一起使用 - 用户将无法添加 SQL 注入。这是如何工作的？

# 没有占位符 - SQL 注入的时机已经成熟！ $STH = $DBH->("INSERT INTO peoples (name, addr, city) values ($name, $addr, $city)"); # 未命名的占位符 $STH = $DBH->("INSERT INTO peoples (name, addr, city) values (?, ?, ?); # 命名占位符 $STH = $DBH->("INSERT INTO peoples (name, addr, city) value (:name, :addr, :city)");

这是我从网站获得的链接，以防您想阅读以供参考。 http://net.tutsplus.com/tutorials/php/why-you-should-be-using-phps-pdo-for-database-access/

【问题讨论】：

它们只是非常草率的例子。他们甚至不会跑。它们缺少->query 和->prepare 方法调用等。
因为命令和数据是分开传输的。（对于那些支持它/启用时的后端。）

标签： php mysql sql security pdo

【解决方案1】：

因为当您使用准备好的语句时，PDO 知道如何正确地将值插入到查询中。

【讨论】：

【解决方案2】：

PDO 在幕后所做的远不止简单地用参数化数据替换占位符。数据库引擎可以接受类似于“这是你的语句，这是占位符，我会告诉你每个占位符中的内容”的形式的查询。 SQL 引擎知道参数不是要执行的原始代码，而是仅被视为数据。

【讨论】：

……如果数据库不支持类似的东西，那么该数据库的 PDO 库将知道如何适当地转义数据本身。
+1。这里非常重要。在几乎所有情况下，替换都是由数据库引擎本身完成的。这意味着我们永远不会出现类似 mysql_escape_string VS 的情况。 mysql_real_escape_string VS。 mysql_escape_string_i_mean_it_this_time.

【解决方案3】：

当您将值绑定到占位符时，例如

$sth->bindValue(':name', $name, PDO::PARAM_STR);

PDO 将负责正确地转义它。因此，SQL 注入将不起作用。

【讨论】：

【解决方案4】：

因为带有绑定参数的预处理语句是查询分析已经完成的语句，而字符串或整数的位置只能是字符串或整数。没有对语句进行新的分析，因此没有给定的参数可以被分析为与 SQL 相关的东西，并且永远不会被分析为 SQL。

【讨论】：

【解决方案5】：

（第二行有一个错误；字符串没有终止。在末尾添加一个");，你应该没问题。它也在你链接的页面上，所以是他们的错。你当然还需要提供将替换问号的值，然后在得到任何结果之前实际运行查询。）

不管怎样，切中要害。 PDO 查找? 或:name 标记，并用您指定的值替换它们（分别按顺序或按名称）。当值被插入到查询字符串中时，它们首先被处理以逃避任何可能用于注入攻击的东西。

这类似于在查询中使用值之前对值使用mysql_real_escape_string()（或较弱的addslashes()），但 PDO 会自动执行此操作并且更胜一筹。

【讨论】：