盲注防御必须使用预处理语句，因过滤函数（如filter_var）仅校验格式，无法阻止合法输入引发的布尔/时间盲注；预处理使输入作为纯数据绑定，不参与sql语法解析，配合错误信息隐藏、响应时间控制及最小权限配置才能有效防护。
盲注防御不能只靠过滤，必须用预处理语句
过滤用户输入（比如用 filter_var() 验证邮箱、整数）能拦住明显非法数据，但对布尔盲注完全无效。攻击者只要输入合法格式的值（如一个真实存在的邮箱、一个看似正常的ID），就能绕过所有过滤，继续试探数据库响应差异。真正起作用的是让输入彻底失去“参与SQL构造”的能力——这只有预处理语句能做到。
使用 PDO 或 mysqli 的预处理机制，SQL结构在执行前已被数据库编译固定，用户输入仅作为纯数据绑定，不会被解析为语法的一部分。哪怕输入是 ' OR 1=1 -- ，数据库也只会把它当做一个字符串值去比对，不可能改变查询逻辑。
- 必须禁用
mysql_query()、mysqli_query()直接拼接字符串的方式，这是盲注的温床 -
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION要开启，否则错误被静默吞掉，反而利于盲注探测 - 不要在占位符位置动态插入表名、列名或
ORDER BY字段——这些必须走白名单校验后硬编码
filter_var() 只适合做输入类型守门员，不是SQL防护层
filter_var() 的作用是快速判断输入是否符合预期格式，比如确认一个参数是不是整数、邮箱是否合法。它不接触SQL执行过程，也不影响查询构造方式，所以不能替代预处理语句。
常见误用场景包括：用 FILTER_VALIDATE_INT 验证后仍拼接进SQL；或用 FILTER_SANITIZE_NUMBER_INT 清洗后再拼接。这两者都毫无防护力，因为清洗后的数字仍是“裸字符串”，照样能被注入利用。
- 正确用法示例：
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT); if ($id === false) { die('Invalid ID'); }，验证通过后，再把$id传给预处理语句的execute() -
FILTER_SANITIZE_STRING在 PHP 8.1+ 已废弃，不要用；需要清理HTML标签时，优先考虑strip_tags()或输出时用htmlspecialchars() - 对自由文本（如搜索关键词）不做强格式限制时，更不能依赖过滤，必须严格走预处理 + 白名单上下文控制（如只允许
LIKE模糊匹配，禁用子查询）
为什么 htmlspecialchars() 对盲注完全没用
htmlspecialchars() 是为防止XSS设计的，作用时机在**输出到HTML页面时**，而盲注发生在**SQL查询执行阶段**。两者所处的处理环节完全不同，混淆使用会导致严重误判。
把用户输入先过一遍 htmlspecialchars() 再塞进SQL，不仅不能防注入，还会导致查询失败（比如查不到带单引号的用户名），甚至引入新的漏洞（如宽字节注入配合转义错乱）。
- 该函数只应在
echo或模板输出前调用，且必须显式指定编码：htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - 数据库写入和读取全程都不应出现
htmlspecialchars()，它不属于数据存储/查询链路 - 富文本内容需用
HTMLPurifier等专用库处理，而非靠htmlspecialchars()应付
容易被忽略的盲注突破口：错误信息与响应时间
即使用了预处理语句，如果错误信息泄露（如显示MySQL版本、表名、字段名），或不同输入导致服务器响应时间有规律差异（如 SLEEP(5) 成功延时），攻击者依然能完成布尔/时间盲注。
这类问题不在代码逻辑层，而在配置和运维层面，常被开发者跳过。
- 生产环境必须关闭
display_errors，并设置log_errors = On，把错误写入日志而非返回给浏览器 - 避免在SQL中使用
IF()、CASE WHEN等可能暴露逻辑分支的结构，尤其不要根据用户输入决定是否延时 - 数据库账户遵循最小权限原则：只授予当前业务所需的表级
SELECT权限，禁用SHOW DATABASES、INFORMATION_SCHEMA访问
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
