Spring Cloud Gateway中应先验签再SQL检测：校验timestamp（±5分钟）和nonce（Redis去重），签名原文须含二者；SQL检测需遍历所有请求参数及JSON嵌套字段，匹配敏感字符和关键词，命中则返回400并告警。
Spring Cloud Gateway 里怎么写 GlobalFilter 拦截 SQL 特征
直接在网关层加 GlobalFilter 是最可控、最前置的方案。它不依赖业务服务是否用了 PreparedStatement，也不管你用的是 MyBatis 还是 JDBC 原生调用。
关键不是穷举所有 SQL 变体，而是盯住高频攻击载荷：
- 遍历
exchange.getRequest().getQueryParams()和exchange.getFormData().awaitSingle()所有值，检查是否含：'、"、;、--、#、UNION、SELECT、INSERT、EXEC（忽略大小写） - 对 JSON Body，必须用
Flux<databuffer></databuffer>异步读取，再用JsonNode递归遍历所有字符串字段——不能只 parse 顶层，深层嵌套字段（如{"filter": {"name": "a' OR 1=1--"}}）照样会漏 - 命中规则时返回
400 Bad Request，附带简短错误码（如{"code":"SQL_INJECT_DETECTED"}），**绝不抛异常、不打印堆栈、不返回原始参数值**，防止信息泄露
为什么 timestamp + nonce 必须和签名原文强绑定
只校验 sign 参数等于没设防。攻击者能重放合法请求，也能固定 nonce 反复改 timestamp 探测窗口。
真实可用的签名校验必须同时满足：
-
timestamp是long类型，且与网关当前系统时间差 ≤300000（5 分钟），超时直接拒 -
nonce长度 ≥ 8，且网关需在 Redis 或本地缓存中记录最近 5 分钟所有已用nonce，重复即拒 - 签名原文必须包含
timestamp和nonce，且二者按字典序拼接——否则攻击者可构造nonce=abc×tamp=1746729600000长期复用 -
appSecret绝不能出现在请求头或 URL；网关必须通过appKey查配置中心动态获取，硬编码等于送密钥
签名验证和 SQL 检测的执行顺序为什么不能错
顺序错了就是开门揖盗。常见错误是“先扫 SQL 再验签”，这会让伪造的 appKey 请求绕过签名校验，直接触发 SQL 检测逻辑。
正确串联流程只有这一种：
- 先验签名：若
sign不合法，连参数都不可信，直接返回401 Unauthorized，不进 SQL 检测 - 签名合法但 SQL 检测失败：说明密钥可能已泄露，或客户端被中间人劫持，此时必须触发告警（如企业微信通知 + 审计日志），不能只返回
400 - 非 JSON 接口（如
application/x-www-form-urlencoded或 GET 参数）同样要覆盖——这类接口常用于搜索、分页，恰恰是 SQL 注入高发区
网关层过滤后，后端还用不用参数化查询
必须用。网关只是第一道过滤，它不替代后端的 PreparedStatement 或 ORM 白名单机制。
比如网关放过一个看似无害的 order by 参数（如 sort=name），后端若用 ${sortField} 动态拼接，仍可能被用于报错注入或时间盲注。
容易被忽略的一点是：网关无法判断某个参数在后端是否被用于动态 SQL 场景。所以哪怕 99% 的请求被网关拦下，剩下那 1% 的漏网之鱼，也得靠后端自己守住最后一道线。
