直接拼接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 异常时，严禁拼接原始用户输入——应记录参数哈希或脱敏后的占位符值
修复的核心不在“怎么让错误不显示”，而在于“让错误根本不暴露数据库结构和查询意图”。哪怕参数化做全了，一条暴露表名的报错，也能帮攻击者省下半小时探测时间。
