SQL注入检测中:如何区分正常请求与恶意注入

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 → 解码为 [email protected]，符合邮箱格式，合法
• 注意：不要盲目全量解码，%u0027（Unicode）或 '（HTML 实体）需按上下文决定是否解析

最常被忽略的一点：业务逻辑变更会让原本安全的输入变成攻击入口。比如新增一个“按 SQL 片段搜索”的功能，WHERE name LIKE '%${input}%' 就不再是漏洞，而是设计意图。检测规则必须与当前接口契约同步更新，否则要么漏报，要么把新功能当攻击打掉。