WAF 在 XSS 与 SQL 注入防御中的作用与局限

Web 应用防火墙（WAF）常被当作 Web 安全的第一道防线。无论是云 WAF 还是自建的 ModSecurity，很多团队在部署之后都会产生一种“攻击已经被挡住了”的安全感。但真实情况是，WAF 既不是万能的，也不是可以替代安全编码的银弹。这篇文章从 XSS 和 SQL 注入两种最常见的 Web 漏洞出发，讨论 WAF 能做什么、不能做什么，以及前端、后端和服务器层面各自应该承担的责任。

WAF 能挡住什么

WAF 的核心能力是基于规则和特征对 HTTP 请求进行检测和拦截。对于 XSS，它可以识别请求参数中出现的 <script>、onerror=、javascript: 等典型 payload；对于 SQL 注入，它可以匹配 UNION SELECT、OR 1=1、SLEEP()、注释符拼接等常见模式。一些商业 WAF 还引入了语义分析和机器学习模型，能够识别经过编码、变形或分片传输的攻击载荷。

在实战中，WAF 的价值主要体现在两个场景：一是为尚未修复的漏洞争取修复时间，二是拦截大规模自动化扫描器和低水平攻击者。这两点对于暴露在公网、迭代速度快的业务来说确实有意义。

WAF 的局限在哪里

WAF 的根本问题在于它是一种“事后匹配”的防御机制。攻击者只要找到一种规则未覆盖的变形方式，就可能绕过。例如：

• 利用数据库特性进行绕过，如 MySQL 中的内联注释 /*!50000SELECT*/、大小写混合、URL 双重编码；
• 利用 HTTP 协议特性，如分块传输（chunked transfer）、参数污染（HPP）；
• 利用业务逻辑漏洞，如通过合法参数组合触发非预期的 SQL 拼接；
• XSS 方面，利用浏览器解析差异、SVG/MathML 标签、DOM 型 XSS 等绕过基于请求体的检测。

此外，WAF 对存储型 XSS 和二阶 SQL 注入的防御能力有限——攻击载荷可能在第一次请求时看起来完全正常，直到被写入数据库并在后续页面中触发。WAF 还面临性能开销、误报导致业务中断、规则维护成本高等工程问题。

结论很明确：WAF 是纵深防御中的一层，不能替代安全编码。

XSS 的常见方式与前端防御

XSS 通常分为三类：反射型、存储型和 DOM 型。反射型通过诱导用户点击携带 payload 的链接触发；存储型将恶意脚本写入数据库，影响所有访问该页面的用户；DOM 型则完全发生在浏览器端，服务端甚至看不到 payload。

前端防御的核心原则是：永远不要将不可信数据当作 HTML 或 JavaScript 执行。

具体做法包括：

1. 输出编码：根据输出位置选择编码方式。HTML 内容用 HTML 实体编码，HTML 属性用属性编码，JavaScript 上下文用 JS 编码，URL 参数用 URL 编码。不要用一套编码应付所有场景。
2. 使用安全的 API：优先使用 textContent 而非 innerHTML，使用 setAttribute 而非拼接属性字符串，避免 eval、new Function、document.write。
3. 框架自带转义：React、Vue、Angular 默认对插值进行转义，但 dangerouslySetInnerHTML、v-html 等逃生舱口需要格外小心，使用前必须经过 sanitize。
4. CSP 作为兜底：内容安全策略（CSP）可以限制脚本来源、禁止内联脚本，即使存在 XSS 漏洞也能大幅降低危害。推荐使用 nonce 或 hash 方式，避免 unsafe-inline。
5. 输入验证：虽然输入验证不能替代输出编码，但对邮箱、URL、数字等有明确格式的字段进行白名单校验，可以减少攻击面。

MySQL 防止 SQL 注入的几种写法

SQL 注入的根源是“用户输入被当作 SQL 代码执行”。防御的核心是让数据和代码分离。

1. 预处理语句（Prepared Statement）

这是最推荐的方式。以 PHP PDO 为例：

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ? AND status = ?');
$stmt->execute([$email, $status]);

参数通过占位符传入，数据库驱动会确保它们只被当作数据。Java 的 PreparedStatement、Python 的 cursor.execute(sql, params)、Go 的 db.Query(sql, args...) 都是同样的思路。

2. 使用 ORM 或查询构建器

Laravel 的 Eloquent、Django ORM、MyBatis 的 #{} 占位符等，底层大多使用预处理。需要注意的是，ORM 中的原生查询方法（如 whereRaw、raw()）如果拼接了用户输入，同样会引入注入。

3. 白名单校验动态部分

表名、列名、排序方向（ASC/DESC）等无法用占位符的位置，必须用白名单映射，绝不能直接拼接用户输入：

$allowed = ['name', 'created_at', 'score'];
$orderBy = in_array($input, $allowed, true) ? $input : 'created_at';

4. 最小权限原则

应用连接数据库的账号只授予必要的权限，例如只读业务表、禁止 FILE、DROP、INTO OUTFILE 等高危操作，可以在注入发生时限制损失范围。

5. 转义作为最后手段

mysqli_real_escape_string 等转义函数在正确使用（配合引号）时可以降低风险，但容易因字符集问题或遗漏而失效，不应作为首选。

Linux 服务器安全加固清单

应用层的防御需要服务器层的配合。以下是一份可落地的加固清单：

• 系统更新：定期打补丁，开启 unattended-upgrades 或使用配置管理工具统一升级。
• 最小化安装：移除不需要的软件包、服务、编译工具，减少攻击面。
• 账户与权限：禁用 root 远程登录，使用 SSH 密钥认证，关闭密码登录；为每个服务创建独立低权限账户。
• SSH 加固：修改默认端口、限制来源 IP、启用 Fail2ban 防暴力破解。
• 防火墙：使用 iptables/nftables 或 ufw 只开放必要端口，默认拒绝入站。
• 文件权限：敏感文件如 /etc/shadow 权限设为 640，Web 目录禁止执行上传文件。
• 日志与审计：启用 auditd，集中收集系统和应用日志，配置告警。
• SELinux/AppArmor：启用强制访问控制，限制服务进程的行为。
• 数据库加固：MySQL 禁止 root 远程访问，删除匿名用户和 test 库，开启慢查询和错误日志。
• 备份与恢复演练：定期备份并验证可恢复性，防止勒索软件和误操作。

结语

WAF 是纵深防御中有效但有限的一层。它能提高攻击成本、争取修复时间，但无法替代参数化查询、输出编码、CSP 和服务器加固。真正可靠的 Web 安全，是把防御责任分散到前端、后端、数据库、服务器和运维流程的每一个环节，让攻击者即使突破一层，也无法轻易得手。

未经允许不得转载：任鹏个人博客 » WAF 在 XSS 与 SQL 注入防御中的作用与局限