如何在Spring Security中协同WAF规则防御SQL注入-mysql教程-PHP中文网

Spring Security 不防 SQL 注入，WAF 需设为“拦截”模式并开启 JSON 解析，Druid wall 仅兜底 Statement 场景，数据库审计须独立且权限最小化。

如何在spring security中协同waf规则防御sql注入

Spring Security 本身不参与 SQL 注入的检测与拦截，它和 WAF 是两类完全不同的防御层——前者管认证授权与 HTTP 头加固，后者才负责实时识别 ' OR 1=1 -- 这类载荷。协同的关键在于：别让 Spring Security 假装在防 SQL 注入，而是确保它不干扰 WAF 的工作，同时补上 WAF 漏掉的环节。

WAF 规则必须开启“拦截”而非“日志”模式

很多团队在云厂商控制台把 WAF 的 SQL 注入防护设为“观察”或“仅记录”，误以为有日志就等于有防护。实际攻击中，UNION SELECT @@version、十六进制编码的 0x554e494f4e（即 UNION）、JSON body 中的 {"id":"1' AND SLEEP(5)--"} 都会被 WAF 语义引擎捕获——但前提是动作设为“拦截”。

检查路径：WAF 控制台 → Web 攻击防护 → SQL 注入 → 动作必须是 拦截，不是 放行 或 记录
对高危接口（如 /api/v1/search、/login）建议加自定义规则：匹配 request_uri 包含 /api/ 且 args 或 request_body 含 SELECT|INSERT|UPDATE|DELETE|EXEC|xp_
确认 WAF 已开启 JSON 解析：否则 POST body 里的 JSON 字段（如 username）不会被解码分析，直接漏过

Spring Security 要避免干扰 WAF 的请求标准化

WAF 依赖统一的请求格式做检测，比如先 urlDecode、再去除空格、再正则匹配。如果你在 Spring Security 的 Filter 里提前重写了 getParameter 或修改了 InputStream，可能导致 WAF 看到的是“二次加工后”的请求体，特征失真。

禁用自定义 HttpServletRequestWrapper 对 getParameter/getInputStream 的无差别重写，尤其不要在过滤器里做 replaceAll 清洗
如果必须做输入处理（如富文本白名单过滤），只针对明确字段名（如 content），跳过通用参数（如 id、q）
Spring Security 的 ContentCachingRequestWrapper 会缓存 body，但某些老版本 WAF 代理模式下可能读不到原始流——测试时用 curl -v 确认 WAF 日志中是否能还原出原始 payload

Druid wall filter 和 WAF 不是叠加关系，而是互补备份

Druid 的 wall filter 是应用内最后一道防线，它不替代 WAF，但能兜底 WAF 漏掉的场景（比如内部直连数据库的管理后台、绕过 Nginx 的调试端口）。它的作用是拒绝非法语法，不是识别攻击特征。

Pi智能演示文档

一款AI演示文稿工具，主要用于领先的AI PPT生成工具，适合需要提升相关任务效率的用户。

下载

配置示例（application.yml）：

spring:
  datasource:
    druid:
      filters: stat,wall
      wall:
        config:
          delete-allow: false
          drop-table-allow: false
          select-all-allow: false

注意：Druid wall 对 PreparedStatement 无效，它只拦截 JDBC Statement 执行的原始 SQL 字符串
它无法防御 MyBatis ${} 拼接或 JPA @Query("SELECT * FROM " + tableName) 这类代码层漏洞——这些必须靠 Code Review 和 SonarQube 规则发现

数据库审计必须独立于业务 DB，否则 WAF + Spring Security 全白搭

WAF 拦住了 99% 的注入请求，但只要一次成功，攻击者拿到 DBA 权限，第一件事就是删日志。这时候如果审计服务和业务库共用一台 ECS 或同个 RDS 实例，所有痕迹都会消失。

必须启用云厂商的独立审计服务（如阿里云 Database Audit Service），走镜像流量或代理模式采集
审计策略至少开启：登录行为、DROP/ALTER/TRUNCATE、SELECT FROM users|orders
审计日志必须存到权限隔离的 OSS Bucket，且禁止 DBA 账号拥有 DeleteObject 权限
特别注意：PAREPARE/EXECUTE 类预编译语句的参数值必须完整记录，否则看不到真实注入 payload

真正容易被忽略的点是时间同步和权限隔离：WAF、审计服务、业务应用三者的系统时间必须通过 NTP 统一，否则日志关联分析会断链；而数据库账号权限最小化（比如查用户接口只给 SELECT user.*）这件事，既不在 WAF 配置里，也不在 Spring Security 里，得靠 DBA 和开发一起落地——它才是让注入即使成功也拿不到数据的最后一道墙。