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

直接拼接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() 或手动双单引号转义——这类方案已被证明在宽字节、多编码场景下失效

生产环境必须关闭详细错误信息，否则等于教黑客写 payload

当 SQL 报错时，如果返回类似 MySQL error 1064: You have an error in your SQL syntax near '...' at line 1 或堆栈里带完整 SQL 语句，攻击者立刻就能确认注入点是否存在、当前数据库类型、表名字段名结构。

实际操作要点：

• Java：Spring Boot 默认开启 server.error.include-message=never，但需检查是否被覆盖为 always
• PHP：确保 display_errors = Off，log_errors = On，错误只记日志不回显
• Node.js：Express 中禁用 app.use(express.errorHandler())，自定义 500 处理器只返回通用提示
• 所有语言：日志中记录 SQL 异常时，严禁拼接原始用户输入——应记录参数哈希或脱敏后的占位符值

修复的核心不在“怎么让错误不显示”，而在于“让错误根本不暴露数据库结构和查询意图”。哪怕参数化做全了，一条暴露表名的报错，也能帮攻击者省下半小时探测时间。