SQL注入漏洞必须从参数绑定堵死所有动态拼接，未用参数化查询即必然被利用；需人工测试、日志审计、ORM层hook、绕过验证及关闭详细错误信息。
SQL注入漏洞必须从参数绑定开始堵死
所有动态拼接 SQL 的写法，无论用 Python、Java 还是 PHP，只要没用参数化查询，就等于在登录框里直接贴上「请黑客输入 SQL」的便签。不是“可能被利用”，是“必然被利用”——只要攻击者知道表名或字段名（而这些往往能从报错、前端 JS 或接口文档里猜到）。
实操建议：
- PHP 用
PDO::prepare()+$stmt->execute()，绝不用mysql_query("SELECT * FROM user WHERE id = " . $_GET['id']) - Python 用
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))，不用f"WHERE name = '{name}'" - Java 用
PreparedStatement，不拼"WHERE id = " + id；MyBatis 也必须用#{id}，禁用${id} - Node.js 用
pg.query("SELECT * FROM users WHERE id = $1", [id])，不写`WHERE id = ${id}`
常见错误现象：SQLSyntaxErrorException: ORA-00933: SQL command not properly ended 这类报错，往往是攻击者试探时触发的，说明后端把原始输入直接塞进了 SQL —— 这已经不是“有没有漏洞”，而是“漏洞是否已被发现”的信号。
漏洞生命周期管理不能只靠扫描器自动标记
扫描器（如 SQLMap、Acunetix）能发现 http://site.com/user?id=1' OR '1'='1 这类典型 payload 触发的报错或行为异常，但对逻辑型注入（比如用 id=1 AND 1=2 推断条件真假）、盲注、二次注入、ORM 层绕过等场景，漏报率极高。靠扫描结果建台账，等于拿体温计当 CT 机用。
实操建议：
- 每个新接口上线前，强制走一次「人工注入测试 checklist」：尝试
'、"、;、UNION SELECT、AND SLEEP(1)，观察响应码、延时、字段数变化 - 把
error_log和数据库慢日志中高频出现的含单引号、UNION、SELECT的 SQL 摘出来，每天扫一遍 —— 真实攻击流量常藏在这里 - 在 ORM 查询构造层加轻量级 hook，记录所有带用户输入的查询语句（脱敏后），一旦发现未绑定参数的 raw SQL 调用，立刻告警
性能影响很小，但能卡住 80% 的“忘了写 ? 占位符”类低级失误。
修复后必须验证绕过路径，尤其注意编码与多层解析
修完一个注入点，不代表它真安全了。攻击者会尝试 URL 编码（%27 代替 '）、Unicode 编码（%u0027）、双写关键字（SELSELECTECT）、大小写混用（SeLeCt）、空字节截断（%00）等手段绕过 WAF 或简单正则过滤。很多团队修完就关 Jira，结果上线三天就被打穿。
实操建议：
- 验证时至少覆盖三类 payload：
id=%27%20OR%20%271%27=%271（URL 编码）、id=1%00' OR '1'='1（空字节）、id=1/**/UNION/**/SELECT（注释绕过空格过滤） - 如果用了 Nginx + ModSecurity，确认规则 ID
942100（SQLi）和942110（布尔盲注）已启用且未被 bypass - 检查中间件（如 API 网关、Spring Cloud Gateway）是否会对参数做二次 decode —— 有些网关先解一次再透传，导致 WAF 检测失效
常见错误现象：403 Forbidden 来自 WAF，但后端日志里仍能看到完整恶意 SQL 执行成功 —— 说明 WAF 在错误位置拦截，或请求根本没经过它。
生产环境禁止开启详细数据库错误信息
psycopg2.ProgrammingError: relation "usersx" does not exist 这种带表名、字段名甚至 PostgreSQL 版本号的错误，等于给攻击者发一张数据库结构地图。开发环境可以开，生产环境必须关，且不能只依赖框架配置 —— 数据库本身也要设防。
实操建议：
- PostgreSQL：设
log_min_error_statement = error，同时client_min_messages = warning，确保客户端收不到DETAIL和HINT - MySQL：启动时加
--skip-show-database，应用连接串里去掉useSSL=false&allowPublicKeyRetrieval=true这类暴露配置的参数 - PHP：关掉
display_errors = Off，并确保error_reporting = E_ALL & ~E_NOTICE不会泄露路径或变量名 - 所有语言统一加一层兜底：HTTP 响应体里只要出现
SQL、ORA-、psycopg2、mysql_字样，立即替换为泛化错误提示
最容易被忽略的是日志文件本身 —— 如果 /var/log/app/error.log 可被 Web 目录遍历访问，那关掉页面报错毫无意义。
