如何修复生产环境中常见的盲注（Blind SQL Injection）漏洞？-SQL-PHP中文网

参数化查询能彻底堵住盲注入口，因为它强制将用户输入视为纯数据而非sql代码，使and 1=1等探测条件无法改变语句逻辑，即使输入含sleep()或恶意子查询，数据库也仅作字面值匹配。

如何修复生产环境中常见的盲注（blind sql injection）漏洞？

盲注无法直接看到错误回显或查询结果，修复时不能只靠“加个 htmlspecialchars”应付——它本质是逻辑泄露问题，必须从数据流源头切断可控输入对SQL执行路径的影响。

为什么参数化查询能彻底堵住盲注入口

盲注依赖的是攻击者通过构造不同条件（如 AND 1=1 / AND 1=2）观察响应时间、HTTP状态码或页面内容差异来反推数据。只要用户输入仍以字符串拼接方式进入SQL语句，无论有没有报错，都可能被用于布尔或时间型探测。

参数化查询（如 PreparedStatement 在 Java、pg_query_params 在 PHP + PostgreSQL、cursor.execute(sql, params) 在 Python + psycopg2）强制将输入视为纯数据，数据库引擎不会解析其内部结构
即使你写了 WHERE name = ?，传入 "admin' AND SLEEP(5)--"，数据库也只会查找字面值为该字符串的记录，SLEEP() 不会被执行
注意：ORM 的 filter() 或 where() 方法若底层未使用预编译（比如某些老版本 Django 的 raw SQL 混用），仍可能绕过防护

字符型盲注常踩的转义陷阱

很多团队误以为对单引号做 addslashes() 或双写（' → ''）就能防盲注，但这是危险的幻觉——尤其在 MySQL 的 sql_mode 不含 STRICT_TRANS_TABLES 时，宽字节注入、编码绕过、多字节截断都可能让转义失效。

Coding Agent Loops

一款AI工具，主要用于在持久tmux会话中运行AI编码代理(Codex、Claude Code)，使用Ralph重试循环和完成钩子处理多步骤编码任务，适合需要提升相关任务效率的用户。

下载

MySQL 中 %df%27（GBK 编码下 %df 和后续 %27 组成合法双字节，使 %27 脱离转义上下文）可绕过 addslashes
PostgreSQL 对单引号双写（''）是标准转义，但若应用层先做了 str_replace("'", "''", $input)，再拼进 SQL，而数据库连接未设 client_encoding=utf8，仍有风险
真正安全的做法是：**完全不拼接**——把所有变量交给驱动处理，连 mysql_real_escape_string 都不该出现在新代码里

时间盲注（Time-based）暴露的权限与配置漏洞

像 AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a', SLEEP(3), 0) 这类 payload 能生效，说明两件事：一是没用参数化查询，二是数据库账户拥有执行 SLEEP / WAITFOR / pg_sleep 的权限。

MySQL 中禁用 SLEEP 需要撤销 EXECUTE 权限：REVOKE EXECUTE ON FUNCTION mysql.sleep FROM 'app_user'@'%';
SQL Server 应避免授予 VIEW SERVER STATE，否则 WAITFOR 可被滥用
生产库账号必须遵循最小权限原则：只给 SELECT / INSERT / UPDATE 所需表，禁用 INFORMATION_SCHEMA 查询（除非业务强依赖）、禁用函数执行、禁用子查询嵌套深度过高（如 MySQL 的 max_allowed_packet 和 sort_buffer_size 也要合理设限）