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

SQL注入攻击的本质，并非什么高深莫测的代码执行漏洞，归根结底是字符串拼接失控导致的——拼接过程缺乏安全校验，使得SQL查询的语义被恶意篡改。攻击者通过精心构造输入参数，将原本正常的查询逻辑彻底带偏。举个例子，攻击者将用户名输入为 ' OR '1'='1 拼接到SELECT语句中，查询条件变成恒真，身份认证直接被绕过。

在实际的SQL注入检测中，这个问题远没有表面看起来那么简单。仅仅盯着单个字符或关键词，根本无法直接判定是否为恶意注入。比如用户在昵称字段中输入 Robert'; DROP TABLE students; --，这显然是典型的SQL注入攻击；但如果输入的是 O'Connor，那只是一个再正常不过的英文姓名。同样，1=1 在系统调试参数中非常常见，但如果出现在登录表单中，性质就完全不同了。真正决定性的判断因素，始终是上下文——即输入内容必须与业务语义和数据类型相匹配。

输入字段的预期类型与实际内容是否匹配

数据库字段的定义规则与前端的表单逻辑设计，共同决定了“什么才算正常请求”。例如订单号字段被声明为 INT 整型，却接收到 1' OR '1'='1 这样的字符串，系统应立即触发告警。而用户名字段允许字母、数字、下划线及单引号，那么 O'Connor 就不应被拦截，它是完全合法的输入。

• 数值型参数中如果出现 '、;、UNION、SELECT 等SQL特殊字符或关键字，基本可以判定为恶意注入请求。
• 字符串型参数中连续出现多个SQL逻辑操作符，例如 AND 1=1 OR 2=2，且没有任何合理的业务含义，必须重点审查。
• 日期字段传入 1970-01-01' AND SLEEP(5) --，类型不匹配且行为异常，属于典型的SQL注入攻击特征。

SQL 关键字出现在非查询上下文中的异常情况

许多安全检测规则一遇到 SELECT 关键字就触发告警，导致误报率居高不下。实际上真正需要关注的，并非关键字本身，而是它出现的位置——是否出现在本不该出现的上下文中。

• GET /search?q=SELECT%20*%20FROM%20users —— 搜索关键词中包含 SELECT，属于正常用户行为，并非SQL注入。
• POST /login username=admin' UNION SELECT password FROM users--&password=123 —— 注意此处 UNION SELECT 出现在 username 参数值中，且紧跟在单引号之后，这才是典型的SQL注入攻击特征。
• Cookie: sessionid=abc123; user_role=admin' AND 1=1 -- —— 在 Cookie 的 user_role 字段值中拼接逻辑表达式，完全违背了角色字段的业务语义。

服务器响应行为暴露异常SQL执行路径

有些请求乍看之下“干干净净”，但服务器的响应方式往往会暴露真实的SQL执行逻辑。这正是绕过静态规则检测的关键突破口。

• 同一个IP对同一接口依次发送 id=1、id=2、id=3，这是正常的浏览行为；但如果请求序列变为 id=1、id=1' and 1=1--、id=1' and 1=2--，那就是典型的SQL注入探测行为。
• 页面响应时间突然大幅增长，例如从80ms飙升至2s，且伴随 SLEEP() 或 WAITFOR 等延时函数构造，基本可以判定为基于时间的盲注攻击。
• 错误信息中直接暴露 Unknown column、MySQL server version、ORA-00904 等数据库原生报错信息，说明错误屏蔽机制未生效，SQL语句已被成功执行。

编码与混淆后的语义还原分析是否合理

攻击者最喜欢使用编码和混淆技术来规避检测，URL编码、十六进制、大小写混用、内联注释等手段层出不穷。安全检测规则必须进行轻量级的解码和归一化处理，才能准确判断其真实语义。

• id=1%20UNION%20SELECT%201,2,3 → URL解码后恢复为 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}%' 就不再是漏洞，而是产品的设计意图。安全检测规则必须与当前接口契约保持同步更新，否则要么导致漏报，要么将新功能误判为攻击而误封。