RASP能自动阻断未知SQL注入，关键在于污点追踪而非正则匹配：标记用户输入为污点→追踪是否参与字符串拼接→判断是否未经净化直接流入JDBC.execute()等执行函数。
RASP 能自动阻断未知 SQL 注入，关键不在于“识别已知 payload”，而在于监控污点数据是否未经净化就流入了 SQL 执行点。它不靠匹配 UNION SELECT 或 -- 这类字符串，而是看“谁拼的、怎么拼的、拼完干了什么”。
SQL 注入检测依赖污点追踪而非正则匹配
RASP 的核心判断链路是：标记用户输入为污点 → 追踪该污点是否参与字符串拼接 → 判断拼接结果是否直接传入 JDBC.execute()、mysqli_query() 等执行函数。只要污点数据在未调用 prepare()、未绑定参数、未经过白名单过滤的情况下，最终进入了 SQL 执行上下文，就会触发阻断。
这意味着即使攻击者用 Base64 编码、十六进制转义、或拆分成多个变量再拼接，只要 RASP 的插桩点覆盖了 String.concat()、StringBuilder.append()、+ 操作符（Java）或 implode()、sprintf()（PHP），就能还原出污染路径。
- 必须启用污点传播插桩，否则只监控执行点会漏掉中间拼接逻辑
- PHP 场景下需确认 RASP 是否 hook 了
mysql_query()、mysqli::query()、PDO::exec()和PDO::query()四类入口，缺一不可 - Java 场景中，若应用使用 MyBatis，RASP 必须能识别
SqlSession.selectList()底层是否实际调用了PreparedStatement；若走的是$rawSql模式，则仍属高危路径
为什么“免重启注入”对阻断未知注入至关重要
很多未知注入利用的是冷门框架特性或新上线接口，等你发现再改代码、发版、重启服务，攻击可能已完成。RASP2.0 的免重启注入能力，让防护策略能实时生效——比如某天新增一个 GraphQL 接口，后端用 String.format() 拼 SQL，只要 RASP agent 已加载，无需任何代码变更，污点一旦流到 Connection.createStatement().executeQuery() 就会被拦。
- 传统 WAF 规则更新需人工研判 + 上线灰度，平均响应时间以小时计；RASP 策略下发是秒级的
- 免重启不等于无侵入：部分 RASP 在 hook
java.lang.StringBuilder时会触发 JVM 类重定义（retransform），需确认目标 JDK 版本支持（JDK8u20+ / JDK11+ 更稳定） - 若业务使用 GraalVM Native Image，标准 Java RASP agent 无法注入，需切换为编译期插桩方案
常见绕过场景及 RASP 的兜底拦截点
攻击者常试图切断污点链来绕过检测，例如把参数从 HTTP 线程传给定时任务线程再执行 SQL。此时 RASP 不会只盯原始线程，而是通过以下方式兜底：
- 监控所有线程创建行为（如
new Thread()、ExecutorService.submit()），一旦发现污点数据被传递进Runnable，立即标记该线程为“污染继承线程” - 对敏感 API 做全局 Hook：不管 SQL 从哪来，只要最终调用
Runtime.exec()、FileOutputStream.write()或Socket.connect()，都视为攻击链延续，触发联动阻断 - JNI 层防御：若 SQL 拼接发生在 native 库中（如某些数据库驱动优化路径），RASP 会在
dlopen()阶段拦截可疑 so/dll 加载，并在Java_com_example_Driver_execute这类 JNI 函数入口做二次校验
真正容易被忽略的不是“能不能拦”，而是“拦在哪一层”。如果 RASP 只在 JDBC execute() 入口做判断，但应用在之前已用 String.replace("'", "''") 做了简单转义，RASP 可能误判为已净化——实际上这种转义在多字节编码或嵌套引号场景下完全失效。所以必须确认 RASP 的净化判定逻辑是否支持上下文感知，比如识别出 addslashes() 对 MySQL 是无效防护，而 mysqli_real_escape_string() 在连接字符集正确时才可信。
