微服务rpc调用中，rpccontext仅可传可信元数据（如traceid、authtoken），业务参数须走标准请求体并在入口显式校验；动态sql字段（如${sortfield}）必须硬编码白名单控制；跨服务返回数据参与本地sql前须重新验证。
微服务 RPC 调用链路中传递上下文本身不解决二次 SQL 注入，但若上下文携带了未经校验的业务数据（如 tenant_id、sortField、tableName），又在下游服务直接拼进 SQL，就会触发二次注入。防范的关键不是“传不传”，而是“传什么、怎么用”。
RpcContext 里只能放可信元数据，不能放用户输入值
很多人把 RpcContext 当成万能管道，把 userId、orgCode、searchKeyword 全塞进去透传。这等于把未消毒的输入从 A 服务“合法转运”到 B 服务，B 服务一不留神用 ${orgCode} 拼 SQL，就中招。
-
RpcContext应只承载调用链元信息：traceId、spanId、authToken（已验签）、clientIp、rpcTimeout、灰度标签（如env=staging） - 所有业务参数必须走标准请求体（HTTP body / gRPC message / Kafka payload），并在每个服务入口做显式校验——哪怕上游是内部服务
- 如果真要透传业务标识（比如多租户场景的
tenant_id），必须在RpcContext中做类型强断言：Long.parseLong(RpcContext.getContext().get("tenant_id").toString())，并捕获NumberFormatException
MyBatis 的 ${} 是二次注入高发区，白名单控制必须硬编码
二次注入最常发生在动态字段拼接环节，比如 ORDER BY ${sortField} 或 FROM ${tableName}。这些字段来自 RPC 上下文或请求体，一旦没白名单校验，攻击者存一条 sortField = "name; DROP TABLE users--" 到数据库，后续查询时就会执行。
- 禁止任何形式的字符串拼接：
"ORDER BY " + sortField、String.format("ORDER BY %s", sortField)都不行 - 白名单必须写死在代码里，不可配置化：
if (!"name".equals(sortField) && !"email".equals(sortField) && !"created_at".equals(sortField)) { throw new IllegalArgumentException(); } - MyBatis 的
<if test="sortField == 'name'">ORDER BY name</if>比${sortField}安全，但前提是sortField已经是校验后的枚举值
跨服务返回的数据必须重新校验，不能信任 RPC 响应体
假设订单服务调用用户服务获取 user.name，用户服务返回 {"name": "admin'; DROP TABLE orders--"}，订单服务直接用这个 name 插入日志表：INSERT INTO log (msg) VALUES ('User: ' || #{name}) —— 看似用了 #{}，但问题出在日志表的 msg 字段后续被另一个报表服务读出、拼进新查询，就构成典型的二次注入。
- 任何跨服务返回的字段，只要可能参与本地 SQL 构建（包括日志、缓存 key、分库分表路由），都必须重新走输入验证流程
- 验证粒度要细：长度限制（如
name≤ 64 字符）、字符集（仅允许a-zA-Z0-9_\-@.）、正则白名单（^[a-zA-Z0-9_\-@.]{1,64}$） - 避免使用
String.valueOf(obj)或obj.toString()获取值——gRPC/JSON 反序列化后可能是恶意构造的子类，toString()可能触发任意代码
Go / Java 中 Raw() 和 executeQuery() 调用必须人工审计
ORM 提供的 Raw()（GORM）、createNativeQuery()（JPA）、executeQuery()（MyBatis）等原生 SQL 接口，绕过了所有框架层防护。它们在二次注入场景中极其危险，因为开发者容易误以为“上游已校验，这里只是读库”，结果把污染数据当参数传进去。
- gosec 规则
G201会标记所有Raw()调用，但工具无法判断你是否真的参数化了——必须逐行确认Raw("SELECT * FROM t WHERE id = ?", id)这样的写法 - Java 中
PreparedStatement的setString(1, unsafeValue)是安全的，但statement.executeQuery("SELECT * FROM t WHERE id = '" + unsafeValue + "'")不是 - 禁止在
Raw()内部嵌套变量拼接：db.Raw("SELECT * FROM " + table + " WHERE id = ?", id)—— 表名部分仍为字符串拼接
真正容易被忽略的是：二次注入的触发点往往不在首次入库，而在某个看似无害的后台任务里——比如定时同步、导出报表、ES重建索引。这些地方的 SQL 构造逻辑常常缺乏输入校验，且运行权限较高，一旦中招后果更严重。
