Web 应用防火墙（Web Application Firewall，简称 WAF）是部署在网站或 Web 应用前面的一道过滤层，会逐个检查进入的网络请求，在可疑请求到达应用之前进行拦截或标记。对于运营网店、预约系统或客户门户的企业，WAF 能多加一层防护，抵御常见的网站攻击；不过它应该和规范的代码、定期更新、日常监测配合使用，而不是替代它们。
WAF 做什么
用户每次打开网页、提交表单或调用 API，浏览器或应用都会发出一个 HTTP 请求。WAF 读取这些请求的内容，包括网址、请求头、Cookie 和表单字段，再和一套规则进行比对。对每个请求，WAF 可以：
- 放行，让请求正常到达网站
- 拦截，并返回错误页面
- 质询，例如验证访问者是不是真实的浏览器
- 记录，留作日后查看而不拦截
规则一般有两个来源：WAF 服务商维护的托管规则，针对广为人知的攻击类型；以及团队为自己网站添加的自定义规则，比如限制同一个地址尝试登录的频率。
WAF 和网络防火墙的区别
传统的网络防火墙根据 IP 地址、端口等条件，决定哪些连接可以进入。它通常不会查看网络请求的具体内容，也不会判断某次表单提交是不是攻击。
WAF 工作在应用层。它默认网站流量本身是允许进入的，再检查每个请求想做什么。大多数企业两者都需要：网络防火墙限制哪些服务能从外部访问，WAF 则负责检查那些必须对外开放的服务收到的流量。
WAF 能帮上什么忙
- 常见的注入攻击，例如藏在表单字段或网址里的 SQL 注入和跨站脚本（XSS）。
- 已知漏洞：广泛使用的软件一旦公开漏洞，WAF 服务商往往会添加规则，拦截已知的利用方式，这种做法有时叫“虚拟补丁”。它可以在完成更新前降低风险，但不能代替更新。我们的 PHP2Shell 文章就是最近的一个例子：服务商加了防护规则，同时仍然建议客户尽快打补丁。
- 自动化滥用，例如机器人反复尝试密码、批量抓取页面或提交垃圾表单，可以通过限流和人机验证来应对。
WAF 做不到的事
- 修复你自己代码里的漏洞。如果已登录的客户只要改一下网址里的编号，就能看到别人的订单，这个请求看起来完全正常，WAF 通常会放行。
- 阻止用被盗密码完成的登录。这类登录和正常登录没有区别，多重身份验证才是更合适的措施。
- 保护能被直接访问的服务器。如果攻击者找到源服务器的地址并绕过 WAF，规则就不起作用。
- 不经调整就完美运行。规则太严会误拦真实客户（误报），太松又会让攻击通过。
WAF 的部署方式
- 云端或边缘 WAF：流量先经过服务商的网络，再到达你的服务器。这类服务常和内容分发网络（CDN）一起提供，一般需要修改 DNS 配置。
- 云平台 WAF：挂在云主机的负载均衡器或网关上。
- 服务器或应用层面：Web 服务器上的模块，或 CMS 里的安全插件。这类方案容易加装，但和被保护的网站运行在同一台服务器上。
选哪一种，取决于你的主机方案、预算和由谁来管理。主机服务商或开发方可以说明现有方案已经包含哪些功能。
稳妥配置的要点
- 先用记录或监测模式，查看哪些请求会被拦截，再把规则切换为拦截。
- 启用规则后测试结账、登录、表单和 API 调用，最好先在预发布环境里测试。
- 在配置允许的情况下，限制源服务器只接受来自 WAF 的流量。
- 继续更新软件和插件。WAF 只是争取时间，并没有消除漏洞。
- 把重要的 WAF 告警纳入网站监测流程，并明确由谁跟进。
- 把 WAF 纳入渗透测试范围，弄清楚它能拦住什么、拦不住什么。
可以向开发方或主机服务商提的问题
- 我们的网站前面有没有 WAF？它是在拦截，还是只做记录？
- 启用了哪些规则？由谁负责更新？
- 如果客户被误拦，由谁处理？
- 源服务器能不能绕过 WAF 被直接访问？
- WAF 的日常检查是否包含在我们的支持服务里？
如需把 WAF、主机和访问权限配置放在一起检查，可以查看 technine.io 的网络安全与合规服务。
常见问题
小企业网站需要 WAF 吗？
只要是带登录、支付或表单的公开网站，不管规模大小，都可能成为自动化攻击的目标。不少主机和 CDN 套餐已经包含基础的 WAF 功能，购买新服务前可以先看看现有套餐。
WAF 会让网站变慢吗？
检查请求需要额外处理，但配置得当的 WAF 一般影响不大。与其凭感觉判断，不如在启用前后实际测一下页面速度。
有了 WAF，还需要更新和测试吗？
需要。WAF 降低的是已知攻击方式带来的风险；更新修复的是漏洞本身，测试则能发现通用规则识别不了的问题。