如何防止User-Agent请求头引发的SQL注入？对非业务参数进行彻底清洗的技巧是什么？

本文共计856个文字，预计阅读时间需要4分钟。

直接修复User-Agent引发的SQL注入问题，核心就是一条：

为什么不能只靠过滤或转义 User-Agent

因为 User-Agent 是完全不可信的客户端输入，长度、编码、字符集全无约束。常见陷阱包括：

• 转义函数依赖当前连接字符集，而 User-Agent 可能含 GBK 多字节编码（如 %A1%27），绕过 mysql_real_escape_string
• 某些框架或旧代码会先做 URL 解码再转义，但解码顺序不一致时会漏掉嵌套编码
• 数据库驱动对空字节、控制字符处理不一，addslashes 对 \0 无效
• 即使你“清洗”了单引号、分号、注释符，攻击者仍可用 extractvalue()、updatexml() 触发报错注入

必须用参数化查询替代字符串拼接

所有将 User-Agent 写入数据库的场景（如日志表 INSERT INTO logs (ip, user_agent)），都得改用预处理语句。