PDO预处理查询：100%防止SQL注入？

引言：困扰每位PHP开发者的问题

如果你曾经用PHP编写过SQL查询，你一定听过这句箴言："使用PDO和预处理语句就能确保安全"。但事实真的如此吗？在Stack Overflow上，"Are PDO prepared statements sufficient to prevent SQL injection?"这个问题获得了数千次浏览和数十场激烈讨论。这绝非偶然。

本文不会简单地给出"是"或"否"的答案。我们将深入PDO底层，剖析预处理语句的工作原理，并揭示即使在PDO的保护下，哪些情况仍可能导致安全漏洞。准备好了吗？让我们开始。

什么是SQL注入？为何如此危险？

在讨论防护措施之前，让我们先认清敌人。SQL注入是一种攻击方式，攻击者通过输入数据"注入"恶意SQL代码。经典案例：

// 危险代码：永远不要这样做\n$username = $_POST['username'];\n$query = "SELECT * FROM users WHERE username = '$username'";\n$result = mysqli_query($conn, $query);\n

如果攻击者输入admin' OR '1'='1，查询将变为：

SELECT * FROM users WHERE username = 'admin' OR '1'='1'\n

瞧——无需密码即可访问数据。如果输入'; DROP TABLE users; --呢？用户表将不复存在。

PDO与预处理语句：工作原理

PDO（PHP数据对象）提供了预处理语句机制。其核心思想是：将查询结构与数据分离。您不再将变量直接拼接到字符串中，而是使用占位符：

// 使用PDO的安全代码\n$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");\n$stmt->execute([':username' => $_POST['username']]);\n

但底层发生了什么？这是许多人忽略的关键点。

模拟模式 vs. 原生预处理语句

PDO可在两种模式下运行：

\n
• 模拟模式（旧版PHP默认） — PDO自行转义数据并在PHP端将其插入查询。这仍然安全，但如果转义机制失效（例如处理非标准编码时），理论上存在漏洞。
\n
• 原生模式 — PDO向数据库服务器发送两条消息：首先是查询模板，然后是单独的数据。服务器将数据作为值处理，而非代码。这绝对安全。
\n

要启用原生模式，请禁用模拟：

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);\n

现在查询分两步发送到服务器。即使攻击者输入' OR '1'='1，MySQL或PostgreSQL服务器也只会将其视为字符串值，而非SQL代码的一部分。神奇吧！

但一切真的完美吗？PDO的潜在陷阱

回到Stack Overflow的问题。答案是"是的，PDO预处理语句足够安全"——但需要满足特定条件。以下情况可能导致防护失效。

1. 动态标识符（表名、列名）

预处理语句仅适用于值（数据）。如果您要插入表名或列名，占位符将无济于事：

// 危险！表名不能通过占位符传递\n$stmt = $pdo->prepare("SELECT * FROM :table WHERE id = :id");\n$stmt->execute([':table' => $_GET['table'], ':id' => 1]); // 错误！\n

PDO只会将表名作为字符串插入，导致查询失败。如果使用模拟模式，攻击者可以输入users; DROP TABLE users; --。解决方案：使用白名单限制允许的值。

2. LIKE查询与通配符

如果您使用