SQL注入本质是字符串拼接导致的SQL语义污染，而非代码执行；其核心在于攻击者通过操控输入改变查询逻辑，如将用户名' OR '1'='1拼入SELECT语句，使条件恒真而绕过认证。
不能靠单个字符或关键词直接判别。比如用户昵称里写 Robert'; DROP TABLE students; -- 是攻击，但写 O'Connor 是合法姓名；1=1 在调试参数里常见，在登录框里出现就危险。关键看上下文是否匹配业务语义和数据类型。
输入字段的预期类型与实际内容是否冲突
数据库字段定义和前端表单逻辑决定了“什么算正常”。比如订单号字段声明为 INT，却收到 1' OR '1'='1，立刻触发告警；而用户名字段允许字母、数字、下划线和单引号，O'Connor 就不该被拦。
- 数值型参数中出现
'、;、UNION、SELECT等，基本可判定异常 - 字符串型参数中连续出现多个 SQL 逻辑操作符（如
AND 1=1 OR 2=2），且无业务意义，需重点检查 - 日期字段传入
1970-01-01' AND SLEEP(5) --，类型+行为双重违规
SQL 关键字出现在非查询上下文中
很多检测规则一看到 SELECT 就报毒，但这是误报高发区。真正该关注的是：这些关键字是否出现在本不该出现的位置。
-
GET /search?q=SELECT%20*%20FROM%20users—— 搜索词里含SELECT是用户行为，不是注入 -
POST /login username=admin' UNION SELECT password FROM users--&password=123——UNION SELECT出现在 username 参数值里，且紧贴单引号后，是典型注入特征 -
Cookie: sessionid=abc123; user_role=admin' AND 1=1 --—— 在 Cookie 的user_role值里拼接逻辑表达式，违背角色字段语义
响应行为暴露异常执行路径
请求本身可能“看起来干净”，但服务器响应会暴露真实执行逻辑。这是绕过静态规则检测的关键突破口。
- 同一 IP 对相同接口连续发送
id=1、id=2、id=3是正常浏览；但id=1、id=1' and 1=1--、id=1' and 1=2--是探测行为 - 页面返回时间突增（如从 80ms → 2s），且伴随
SLEEP()或WAITFOR类构造，极可能是基于时间的盲注 - 错误信息包含
Unknown column、MySQL server version、ORA-00904等数据库原生报错，说明未做错误屏蔽，SQL 已被执行
编码与混淆后的语义还原是否合理
攻击者常用 URL 编码、十六进制、大小写混用、内联注释等方式绕过规则。检测必须做轻量级解码和归一化，再判断语义。
-
id=1%20UNION%20SELECT%201,2,3→ 解码为id=1 UNION SELECT 1,2,3，语义清晰，非法 -
id=1/**/UNION/**/SELECT/**/password/**/FROM/**/users→ 去除注释后仍是完整联合查询，非法 -
email=test%40example.com→ 解码为test@example.com，符合邮箱格式，合法 - 注意：不要盲目全量解码，
%u0027（Unicode）或'（HTML 实体）需按上下文决定是否解析
最常被忽略的一点：业务逻辑变更会让原本安全的输入变成攻击入口。比如新增一个“按 SQL 片段搜索”的功能，WHERE name LIKE '%${input}%' 就不再是漏洞，而是设计意图。检测规则必须与当前接口契约同步更新，否则要么漏报，要么把新功能当攻击打掉。
