SQL注入漏洞本质是未过滤用户输入导致恶意SQL执行，修复核心是禁用字符串拼接、强制使用参数化查询，尤其对不可信的User-Agent字段。
直接修复 User-Agent 引发的 SQL 注入，核心就一条：绝不把它拼进 SQL 字符串。哪怕你加了 mysqli_real_escape_string 或双单引号转义，只要还在用字符串拼接，就等于给攻击者留了缝。
为什么不能只靠过滤或转义 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。
