RASP对SQL注入的实时阻断依赖在JDBC关键执行点（如Statement.execute()）埋点监控实际SQL与用户输入的污点传播，而非字符串特征匹配；它运行于JVM内部，获取解码后的完整SQL和变量值，检测精度远超仅能猜测意图的WAF。
RASP 对 SQL 注入的实时阻断，不是靠“识别字符串特征”，而是靠在 JDBC 执行链路关键节点（如 PreparedStatement.execute()、Statement.execute()）上埋点，监控实际执行的 SQL 语句是否混入了未经净化的用户输入。它不看请求里有没有 ' OR '1'='1，而看最终拼出来的那条 SQL 是不是把 HTTP 参数原样塞进了查询。
为什么不能只靠 WAF 或正则匹配？
WAF 在网络层看到的是编码后、混淆后、甚至加密后的流量，比如 %27%20OR%20%271%27%3D%271 或 base64 编码的 payload；它只能靠规则猜意图，容易被绕过。而 RASP 运行在 JVM 内部，当业务代码调用 statement.execute("SELECT * FROM users WHERE name = '" + name + "'") 时，它拿到的是解码还原后的完整 SQL 字符串和变量值——此时攻击已“落地”，检测精度极高。
Java RASP 是如何 Hook SQL 执行点的？
主流 Java RASP（如 OpenRASP、自研探针）依赖 java.lang.instrument 和字节码插桩，在类加载阶段修改以下目标方法的字节码：
-
java.sql.Statement.execute(String)、.executeQuery(String)、.executeUpdate(String) -
java.sql.PreparedStatement.execute()及其变体（注意：这里不拦截参数绑定动作，而是拦截最终执行时刻） -
javax.persistence.Query.executeUpdate()/.getResultList()（对 JPA 场景补充覆盖）
插桩后，每次执行前会触发检测逻辑：提取 SQL 字符串 + 回溯调用栈 + 检查是否有未消毒的 request 参数参与拼接。一旦确认污点数据（taint）流到了 SQL 执行上下文，立即抛出异常或中断执行。
真实场景中容易被忽略的绕过点
不是所有 SQL 执行路径都被默认覆盖。以下情况常见于生产环境且易漏防：
- 使用
MyBatis的${}语法（非#{}）直接拼接 SQL：RASP 必须额外 HookSqlSession.selectList()等入口，否则无法感知字符串拼接行为 - 通过反射调用
Statement方法：绕过常规方法签名匹配，需开启更激进的类加载期全量扫描（影响启动性能） - 异步线程中执行 DB 操作（如
CompletableFuture.supplyAsync()）：若 RASP 的污点传播未跨线程继承，会导致上下文丢失，检测失效 - ORM 框架自定义方言（如 Hibernate Spatial、ShardingSphere 分片路由）：SQL 构造发生在框架内部私有方法，标准 Hook 点可能未覆盖
这些都不是配置开关能解决的，必须结合应用实际技术栈做 Hook 点校验与扩展。
部署后必须验证的三件事
装完探针别只看控制台“在线”就以为万事大吉：
- 用真实测试用例触发一次
' OR '1'='1登录绕过，确认返回是 403 或空响应，而不是数据库报错页面 - 检查日志中是否出现
RASP_BLOCKED_SQL_INJECTION类似标记，以及完整的调用栈和原始 SQL - 验证非 HTTP 入口（如定时任务、消息队列消费者）发起的 SQL 是否也被监控——这部分常被当成“可信上下文”而跳过检测
真正难的不是加探针，而是确认它在你用的所有框架、所有线程模型、所有 SQL 构造路径下都持续生效。漏掉一个执行分支，就等于留了一扇没锁的窗。
