如何防止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)），都得改用预处理语句。以 PHP + MySQLi 为例：

$stmt = $mysqli->prepare("INSERT INTO logs (ip, user_agent, created_at) VALUES (?, ?, NOW())"); $stmt->bind_param("ss", $_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_USER_AGENT']); $stmt->execute();

关键点：

• bind_param("ss", ...) 中的 s 表示字符串类型，底层由驱动处理序列化，不经过 SQL 解析器
• 即使 $_SERVER['HTTP_USER_AGENT'] 是 Mozilla/5.0' OR SLEEP(5)--，也只会作为纯值插入，不会触发执行
• 不要试图先截断长度再拼接——参数化本身已解决长度和编码问题

如果必须记录原始 User-Agent 且无法改代码结构

极少数遗留系统不允许动 SQL 构造逻辑，此时只能做“隔离式清洗”，但这是下策：

• 用白名单限制字符：只保留 ASCII 可见字符（[\x20-\x7E]），丢弃所有 Unicode、控制符、空字节
• 强制截断到 200 字节以内（substr($ua, 0, 200)），防止长 payload 溢出或触发缓冲区异常
• 替换所有单引号为两个单引号（str_replace("'", "''", $ua)）——仅对 SQL Server 有效；MySQL 要用 mysqli_real_escape_string，但前提是连接字符集已设为 utf8mb4
• 绝对不要用 strip_tags()、htmlentities()，它们不防 SQL 注入，只防 XSS

日志场景下更安全的替代方案

多数业务记录 User-Agent 仅为统计或调试，根本不需要进主业务库。推荐拆离：

• 写入独立日志表（如 access_logs），该表不参与任何业务查询，权限仅限 INSERT
• 用消息队列（如 Redis List / Kafka）异步落盘，Web 层只 push，不直连 DB
• 前端埋点上报到专用分析服务（如 Matomo、自建 ClickHouse），彻底剥离 Web 应用与 UA 存储逻辑

真正难的不是写对那行 bind_param，而是确认所有调用链路——比如中间件、审计钩子、ORM 的 save() 方法、甚至 Log4j 的 JDBC appender——有没有哪一处悄悄把 User-Agent 拼进了 SQL。