盲注防御关键在于抹平响应差异：统一HTTP状态码、响应体长度与耗时，禁用Spring Boot默认危险配置，并在网关层监控异常请求模式。
Blind SQL注入不能靠返回内容判断，得靠时间差、布尔响应或错误日志间接探测——所以防御重点不是“拦住所有可疑字符”，而是让攻击者根本无法从响应中提取任何可利用的信号。
为什么移动端API特别容易被盲注盯上
移动App的接口通常不返回完整SQL错误（这是对的），但开发者常忽略两点：一是HTTP状态码暴露逻辑分支（比如200 vs 404表示用户是否存在），二是响应时间未做统一控制。攻击者用AND SLEEP(5)或AND (SELECT COUNT(*) FROM users)>100反复试探，靠毫秒级延迟或成功/失败差异就能还原出数据库内容。
- 常见场景：手机号登录校验、订单号查询、设备绑定验证等“存在性判断”接口
- 典型漏洞写法：
SELECT id FROM users WHERE phone = '${phone}'—— 拼接未参数化，且没加统一超时兜底 - 危害比显式注入更隐蔽：日志里看不到
UNION SELECT，但攻击者已批量导出用户手机号
Java/Spring Boot中必须关闭的三个默认行为
Spring Boot默认配置会悄悄放大盲注风险，尤其在开发环境启用时：
- 禁用
spring.sql.init.mode=always：该配置可能在启动时执行脚本，若含动态拼接，易被利用 - 关闭
server.error.include-message=always：避免把org.springframework.dao.DataIntegrityViolationException这类异常名直接透出到响应体 - 禁用
spring.jpa.show-sql=true和hibernate.format_sql=true：生产环境日志里出现原始SQL，等于给攻击者送字典
这些配置在application-prod.yml里必须显式设为never或false，不能依赖profile继承默认值。
如何让布尔盲注失去区分能力
核心思路是“抹平响应差异”：让合法请求和恶意布尔探测的HTTP状态码、响应体长度、耗时全部趋同。
- 所有数据库查询统一包装在
try-catch块中，捕获DataAccessException后返回400 Bad Request，而不是根据异常类型返回404或500 - 对“存在性判断”接口（如查用户是否注册），强制走异步+缓存兜底：先查Redis缓存，命中则直接返回；未命中才查DB，但无论查到与否，都统一返回
{"exists": true}或{"exists": false}，字段名和结构完全一致 - 在网关层（如Spring Cloud Gateway）加
ResponseTimeFilter，对所有下游响应强制加入Thread.sleep(300)（300ms基线），消除SLEEP类时间差探测的基础
真正起效的检测点不在SQL语句里
盲注载荷往往绕过常规关键词过滤（比如用ELT(1,1,2)代替IF，用ASCII(SUBSTR(...))逐字节猜解）。与其在网关层穷举变体，不如监控三类异常模式：
- 同一
appKey在5分钟内发起>20次带AND/OR且参数值含单引号的请求 → 触发限流+告警 - 请求URL中
keyword、id等参数连续出现substr、ascii、length等函数名 → 直接拦截 - 某IP在10秒内对同一接口发起8次以上，且每次响应时间标准差>200ms → 记录并冻结该IP 1小时
这些规则要部署在网关层，且必须和签名校验强绑定——先验timestamp和nonce，再跑SQL特征扫描，否则攻击者伪造appKey就能绕过全部检测。
