二次sql注入触发点在数据取出并拼入新sql时，而非输入环节；恶意payload经安全存储后，在后续查询中因信任数据库数据而未经校验直接拼接，导致防护失效。
二次SQL注入的触发点根本不在输入环节
常规输入验证只拦得住“第一次提交”，但二次注入的恶意 payload 是在数据取出、拼进新 SQL 时才真正起效。比如用户注册时填入 admin' OR '1'='1，当时被 mysqli_real_escape_string() 或参数化安全存入数据库，日志无异常、WAF 不拦截、前端校验也通过——它看起来完全合法。问题出在三天后，后台导出报表时从 DB 查出这个值，直接拼进 "WHERE username = '$username'"，此时输入验证早已失效。
数据库字段≠可信输入，但开发者常默认它可信
多数人潜意识里认为“从数据库读出来的数据是干净的”，尤其当它来自自己系统的表。这种信任链断裂是二次注入最隐蔽的根源。常见错误包括：
- 用
$row['nickname']直接传给whereRaw("nickname = '{$nickname}'")（Laravel/Eloquent 场景） - 从 Redis 缓存取
$table_name后拼"SELECT * FROM {$table_name}"，跳过所有 ORM 校验层 - 日志模块把
$user_remark原样写进INSERT INTO audit_log (remark) VALUES ('{$remark}')
字符集切换会让“转义”在读取时彻底失效
mysqli_real_escape_string() 的结果依赖当前 MySQL 连接的字符集。入库时用 utf8mb4 转义成功，但读取时连接可能已切到 latin1，导致 admin\'-- 被解析回原始恶意字符串。更关键的是：
- 它不处理
UNION、ORDER BY、GROUP BY等关键字 - 对动态表名、字段名、LIMIT 子句等零防护
- 数字上下文（如
id = $id）中，即使转义了单引号也完全无效
静态扫描和单元测试天然漏掉“存储→取出→再拼接”链路
自动化工具通常只分析单次请求的输入输出，无法追踪跨模块、跨时间的数据流转。比如：
- SQLMap 扫注册接口，发现不了 INSERT 安全但后续 UPDATE 被污染的问题
- 代码审计只看
get_user_by_id()函数，忽略它返回的$row['sort_field']被传给orderByRaw("{$field}") - 单元测试 mock 输入，但不会构造一条含
' OR 1=1的真实 DB 记录来跑闭环
真正要防住，得在每次从 DB/缓存读出变量、且该变量即将参与 SQL 拼接前那一行代码处，做白名单或强类型校验——而不是指望“当初输进来时已经验过了”。
