API网关层能捕获布尔盲注，因其可观察高频、微变、稳态响应的行为模式，而应用层已统一响应格式丢失判断依据；关键特征是同一路径下短时内参数末尾渐变、响应长度稳定、状态码全200；Nginx/Envoy应基于滑动窗口聚合请求流，检测请求数≥12、响应体标准差≤8、长度差≤12且全200即告警限流。
API网关层为什么能捕获布尔盲注，而不是等它进到应用层？
因为布尔盲注不依赖报错或回显，它靠反复发送真假条件（比如 id=1 AND 1=1 vs id=1 AND 1=2），观察响应体、状态码、响应头或响应时间的细微差异来推理数据。这些差异在网关层就已固化为可观测信号——而应用层可能早已把真假响应统一格式化成 {"code":200,"data":null} 或兜底成500，丢失了原始判断依据。
网关是所有请求的必经关口，也是唯一能同时看到“输入参数 + 原始响应特征 + 请求频次 + 客户端指纹”的位置。你不需要解析SQL，只需要识别行为模式。
哪些HTTP特征组合强烈暗示布尔盲注？
布尔盲注不是单个请求就能定性的，必须看一组请求的横向对比。重点关注以下三类信号叠加：
-
GET或POST请求中，同一接口路径下连续出现多个仅在查询参数值末尾变动的请求，例如：/api/user?id=123、/api/user?id=123%20AND%20SUBSTRING((SELECT%20password%20FROM%20users%20LIMIT%201),1,1)='a'、...='b'、...='c' - 这些请求的响应体长度差值稳定在 ±10 字节以内，但状态码全为
200（说明没触发异常，也未被WAF拦截） - 同一客户端IP/UA在60秒内发起 ≥15次该路径请求，且参数长度逐次增长（典型盲注fuzz节奏）
注意：单独看某一次 AND 1=1 没意义；真正危险的是“高频+微变+稳态响应”的三角组合。
用Nginx或Envoy做实时检测时，关键配置点在哪？
不要试图在网关里写SQL解析器。应基于OpenResty（Nginx）或Envoy WASM模块做轻量规则匹配：
- 对
location /api/类路径启用log_by_lua_block（OpenResty）或envoy.filters.http.ext_authz（Envoy），记录每个请求的：-
$args（原始查询字符串，未解码） -
$body_bytes_sent（响应体字节数） $status-
$request_time（精度到毫秒）
-
- 在内存中维护一个滑动窗口（如最近30秒），对同一
$remote_addr+$uri组合聚合请求流 - 当满足：请求数 ≥12 && 平均响应体标准差 ≤8 && 最大最小长度差 ≤12 && 所有
$status == 200→ 触发告警并临时限流
这个逻辑不依赖数据库指纹，也不需要知道后端用MySQL还是PostgreSQL，只认行为。
为什么不能只靠WAF规则库？
主流WAF（如ModSecurity CRS、云厂商默认策略）对布尔盲注检出率普遍低于35%，原因很实在：
- 规则依赖关键字匹配（如
AND 1=1），但攻击者早用AND/**/1=1、AND(1)=1、AND SLEEP(0)绕过 - WAF无法感知“同一IP对同一接口的请求节奏”，把正常批量查ID当成攻击会误杀
- 真实业务中存在大量合法的动态拼接场景（如低代码平台导出条件、BI拖拽筛选），WAF一刀切容易阻断功能
真正有效的防御，是把网关变成一个“行为审计探针”，而不是“语法过滤器”。复杂点在于你需要自己定义滑动窗口的聚合粒度和阈值——太松漏报，太紧误伤。这没有标准答案，得根据你的真实流量基线调。
