如何防止SQL注入攻击_使用预编译语句参数化查询

SQL字符串拼接危险因用户输入直接混入SQL，导致注入攻击；须用参数化查询并禁用模拟预处理，严格匹配占位符与参数类型及顺序。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么 string + SQL 拼接是危险的

问题的根源在于，当用户输入被直接“揉”进SQL语句字符串时，数据库引擎根本无法分辨哪些是预设的逻辑，哪些是不可信的数据。一个经典的例子是，如果用户输入了 ' OR 1=1 --，拼接后的语句就会变成 SELECT * FROM users WHERE name = '' OR 1=1 --'。结果呢？整个用户表的数据都可能被泄露。

下面这些写法，是不是看着很眼熟？mysql_query("SELECT * FROM user WHERE id = " . $_GET['id'])，或者 f"SELECT * FROM log WHERE msg = '{user_input}'"。必须指出，即便你在拼接前加了 trim() 或 intval() 这类过滤，也未必能防住多字段组合注入或时间盲注等高级攻击手法。

• 一个核心原则是：所有动态值——无论是数字、字符串，甚至是极少情况下需要动态指定的列名或排序方向——都绝对不应该通过字符串拼接的方式进入SQL。
• 列名和表名本身无法使用参数占位符。如果业务逻辑必须动态指定，那么唯一安全的做法是采用白名单校验，例如只允许从 ['name', 'email', 'created_at'] 这个预设列表中选择。
• 排序方向（ASC/DESC）同样不能参数化。安全的做法是使用类似 in_array($dir, ['ASC', 'DESC']) 的代码进行严格过滤。

PHP 中用 PDO::prepare() 和 bindValue() 的硬性姿势

这里有个常见的误区：不是调用了 prepare() 方法就万事大吉了。真正的安全关键在于确保“数据值不进入SQL字符串”。你知道吗？PDO默认是开启模拟预处理模式的（PDO::ATTR_EMULATE_PREPARES = true）。在某些版本或特定查询（如包含 LIKE 子句或类型不匹配）时，它可能会在底层退化成字符串拼接，让所有的防护努力前功尽弃。

因此，实操中务必遵循以下几点：

• 创建PDO实例后，第一件事就是显式关闭模拟预处理：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)。
• 优先使用 bindValue() 而非 bindParam()，除非你确实需要变量引用的特性。bindValue() 的行为更直观，类型控制也更明确。
• 绑定参数时，务必明确指定类型。例如，数字用 PDO::PARAM_INT，这能避免字符串被意外当作数字解析而引发错误。
• 来看一个标准示例：$stmt = $pdo->prepare("SELECT * FROM posts WHERE status = ? AND created_at > ?"); $stmt->bindValue(1, 'published', PDO::PARAM_STR); $stmt->bindValue(2, $since, PDO::PARAM_STR);

Python 的 sqlite3 和 psycopg2 参数占位符别混用

不同的数据库驱动，其参数占位符的语法也各不相同。这是一个极易踩坑的地方：用错一个符号，参数化查询就可能悄无声息地退化为危险的字符串拼接，而且系统往往不会报错。比如，sqlite3 只认 ? 或 :name 这种命名占位符，而 psycopg2（用于PostgreSQL）则使用 %s（注意，这里统一用 %s，而不是 %d 或 %f）。一旦混淆，SQL注入的大门就敞开了。

常见的翻车现场包括：

• 在 psycopg2 中写成 "WHERE id = %d" % user_id —— 这其实是Python的字符串格式化，并非数据库驱动的参数化绑定。
• 使用 f-string 提前构造语句：f"WHERE name = '{name}'" —— 即便后续将这个字符串传给 cursor.execute(...)，也为时已晚，数据已经拼接进去了。
• 误以为 sqlite3 的命名参数可以用于列表：WHERE name IN (:names) 是无效的。正确做法是将列表展开为多个 ?，如 WHERE name IN (?, ?, ?)，再进行绑定。
• 正确示例（psycopg2）：cursor.execute("SELECT * FROM orders WHERE user_id = %s AND status = %s", (uid, 'shipped'))

Node.js 里 pg 和 mysql2 的参数位置不能手滑

Ja vaScript作为一种动态语言，缺乏编译期的严格检查。这意味着，如果占位符和传入的参数数组对不上号，轻则导致查询不到预期数据，重则可能完全绕过参数化机制。例如，在PostgreSQL的 pg 驱动中，如果你写了两个 $1 却只传一个值，它会报错；但如果你不小心写成了字符串模板拼接，它就会默默地执行那个不安全的查询。

以下几个细节必须盯紧：

• pg 驱动使用 $1, $2 这种位置占位符，其顺序必须严格对应参数数组的元素位置，不能跳号，也不能重复。
• mysql2 驱动使用 ? 占位符，同样是按从左到右的顺序替换。它虽然支持通过配置开启命名占位符模拟（namedPlaceholders: true），但底层仍会转换为 ?，使用时需注意版本兼容性。
• 切记，绝对不要在SQL字符串中间出现 ${}（模板字符串）或 +（字符串连接）来进行拼接，哪怕你只是想加个空格——像 `WHERE id = ${id} AND active = 1` 这样的写法，就是典型的高风险代码。
• 示例（pg）：client.query('SELECT * FROM products WHERE category = $1 AND price

最后，也是最容易被忽视的一点：使用ORM（对象关系映射）框架并不等于绝对安全。以TypeORM为例，find({ where: { name: req.query.q } }) 这种写法看起来挺安全，但如果前端传来的 q 参数是一个像 { $like: '%admin%' } 这样的对象，并且框架没有关闭对原始操作符的支持，那么注入攻击依然可能发生。所以，参数化的精髓不在于“是否使用了某个高级工具”，而在于“每一个动态值是否都严格走了绑定通道”。这才是构筑数据库安全防线的根本所在。