怎样修复因SQL拼接导致的数据库敏感信息泄露漏洞？

作者：袖梨 2026-06-24

直接拼接SQL语句是最危险的写法，等同于将数据库钥匙交给用户；攻击者输入admin'--或' OR '1'='1即可绕过验证、窃取数据；必须使用参数化查询（如PreparedStatement、PDO预处理），辅以输入验证和最小权限原则。

直接拼接 `username` 和 `password` 是最危险的写法

只要看到类似 "SELECT * FROM users WHERE name = '" + username + "' AND pw = '" + password + "'" 这种字符串拼接，就等于把数据库钥匙塞进用户手里。攻击者输个 admin'-- 或 ' OR '1'='1，就能绕过验证、查出所有用户数据，甚至拖库。

这种写法在 Java、PHP、Python（用 str.format 或 % 拼接）、Node.js（query = "SELECT ... WHERE id = " + req.query.id）里都反复出现，不是“老项目才这样”，而是“没改就一直存在”。

它不依赖数据库类型——MySQL、PostgreSQL、SQL Server 全部中招
ORM 也不能自动免疫：比如 Django 的 raw()、SQLAlchemy 的 text()、MyBatis 的 ${}（非 #{}）照样会拼接
日志里打印完整 SQL 语句时，如果含用户输入，还会二次泄露敏感字段（如身份证、手机号）

`PreparedStatement` 不是可选项，是唯一安全路径

Java 里必须用 PreparedStatement，而不是 Statement；Python 用 cursor.execute(sql, params) 而不是 cursor.execute(sql % params)；PHP 用 PDO 的 prepare() + execute()，而不是 mysql_query() 或 mysqli_query() 拼接。

关键不是“用了预编译”，而是参数是否真正绑定到占位符上：

✅ 正确：SELECT * FROM users WHERE id = ? + setInt(1, userId)
❌ 错误："SELECT * FROM users WHERE id = " + userId（哪怕加了 Integer.parseInt()，仍可能被绕过）
❌ 危险：SELECT * FROM users WHERE name = ${name}（MyBatis 中的 ${} 直接字符串替换）

注意：MySQL 的 LOAD_FILE()、INTO OUTFILE 等高危函数，即使用了 PreparedStatement，如果数据库账号有对应权限，依然能被调用——所以必须配合最小权限原则。

输入验证不能替代参数化，但能快速堵住已知攻击模式

参数化解决的是“执行逻辑被篡改”，而输入验证解决的是“不该进来的根本别让它进来”。两者不是二选一，是必须叠加。

常见有效做法：

对数字型参数（如 id、page）直接转为整型并校验范围，拒绝非数字字符
对用户名、邮箱等字段用白名单正则：^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$，而非简单过滤单引号
对搜索关键词类字段（如 q=xxx），允许有限通配符（如 %），但禁止 '、;、--、/*、UNION、SELECT 等关键字出现在原始输入中
避免用 mysql_real_escape_string() 或手动双单引号转义——这类方案已被证明在宽字节、多编码场景下失效