User-Agent易被绕过因常被直接拼入SQL且逃过表单校验；验证方式为修改UA为' OR 1=1 -- 观察报错或异常；防御须用mysqli_real_escape_string()或预处理，而非仅htmlspecialchars()。
为什么User-Agent字段容易被绕过过滤
因为绝大多数应用只对 $_POST 和 $_GET 参数做 check_input() 这类显式校验，而 $_SERVER['HTTP_USER_AGENT'] 是全局变量，常被直接拼进 SQL 语句——比如日志记录、设备统计、风控埋点等场景。它不走表单提交流程，自然也逃过了你写在登录逻辑里的那层过滤。
如何验证User-Agent是否参与数据库操作
先确认它是否真进了 SQL：抓包改 User-Agent: ' OR 1=1 -- ，看响应是否报错或行为异常（如页面多返回一条数据、日志写入失败、HTTP 500）。常见可触发点包括：
INSERT INTO uagents (uagent, ip_address) VALUES ('$uagent', '$IP')UPDATE stats SET ua_count = ua_count + 1 WHERE ua LIKE '%$uagent%'SELECT * FROM devices WHERE browser = '$uagent'
只要字符串没经过 mysql_real_escape_string()、addslashes() 或参数化处理，就极可能中招。
实际防御时最容易忽略的三个点
不是加个 htmlspecialchars() 就完事——那是防 XSS 的，对 SQL 注入无效。真正起作用的是：
- 用
mysqli_real_escape_string()或PDO::quote()处理$uagent，而不是靠正则删单引号（攻击者可用十六进制、宽字节、注释符绕过） - 所有 Header 字段（
Referer、X-Forwarded-For、Cookie）只要进 SQL，就得统一走预处理——别只防User-Agent而漏掉Referer，后者在跳转来源统计里同样高频入库 - 避免在日志 SQL 中直接拼接原始 Header 值；更稳妥的做法是先用
substr($uagent, 0, 255)截断 +mb_convert_encoding()归一化编码，再进预处理
为什么WAF不能代替代码层修复
Cloudflare 或 Nginx WAF 规则依赖特征匹配，而 User-Agent 合法值本身千变万化（含括号、斜杠、空格、Unicode），规则稍严就误杀正常请求，稍松就放过 ')) OR SLEEP(5)-- 这类变形 payload。真实攻防中，90% 的 Header 注入利用都发生在 WAF 规则盲区——比如把 SLEEP() 拆成子查询嵌套、用 IF 函数包裹、或混用大小写与 URL 编码。最终防线永远在你自己的 prepare() 调用里。
