什么是 WAF？

Scrapeless Web Unlocker 从目标 URL 检索网页内容，并为被允许的采集工作流提供 JavaScript 渲染支持。

什么是 Web 应用防火墙？

Web 应用防火墙（WAF）会检查 Web 应用程序流量，并应用可以监控、允许或阻止交易的规则。它的重点在于应用层的交互，包括 HTTP 请求的结构和内容。WAF 可以帮助保护应用程序，但不能替代安全的应用程序设计或授权机制。

The OWASP 对 Web 应用防火墙的定义 将控制置于 Web 应用层。这一点使其有别于基本的网络过滤器，后者主要根据地址、端口和传输连接来做出决策。

WAF 可以通过边缘基础设施、反向代理或应用程序请求路径中的其他组件进行部署。部署方式决定了该控制能够检查什么以及可以在何处执行决策。仅凭产品名称无法描述该架构。

WAF 在请求路径中的位置在哪里？

WAF 位于检查点处，相关的应用程序流量会通过该检查点。在反向代理架构中，客户端会连接到能够在将请求转发到源应用程序之前对其进行检查的基础设施。

加密流量带来了可见性需求。某个组件需要访问解密后的 HTTP 内容才能检查该内容。TLS 终止器和 WAF 可以属于同一个服务，也可以是独立组件。绘制实际的流经路径，而不是假设每个中间环节都能看到相同的数据。

The HTTP 协议的请求和响应语义 提供检查逻辑所解释的结构。方法、目标、标头和表示数据都可能与规则相关。特定部署是否检查主体以及检查到何种程度，都是配置问题。

源可达性也是架构的一部分。若某个未受保护的路由直接访问同一应用，边缘检查并不会自动覆盖该路径。所有者应盘点公共入口点，并确认哪些流量实际经过预期的控制措施。

WAF 规则如何做出决策？

WAF 规则会将观测到的事务特征与已配置的条件进行比较。规则可以用于查找已知的攻击模式、无效的协议结构、意外的参数，或由操作员定义的自定义条件。

否定规则用于识别不需要的模式。肯定规则描述允许的结构，例如已知的参数结构。两种方法都需要了解正常的应用行为。范围宽泛的模式可能匹配合法输入，而范围狭窄的规则可能会遗漏意料之外的攻击形式。

某些规则集使用异常评分。单个匹配会对交易分数产生贡献，而由单独的策略来决定累积结果是否足以触发拦截。 核心规则集异常评分模型 将检测逻辑与最终的破坏性操作分离开来。

在事故审查过程中，这一区别非常重要。被记录的规则匹配并不总是意味着请求被阻止。相反，最终的阻止事件可能会汇总之前的多次匹配。在修改日志中最接近末尾的那条规则之前，请先阅读完整的事务上下文。

规则顺序、排除项、检查阶段和执行模式都会影响结果。这些细节属于特定的引擎和配置。避免在未确认适用性的情况下，将某个安装中的阈值或规则标识符沿用到另一套安装中。

WAF、网络防火墙、机器人管理和授权

WAF、网络防火墙、机器人管理和应用程序授权回答的是相关但不同的问题。一个平台可能会同时提供其中的多种功能，但在运维上划清边界依然是有益的。

一个请求可以通过 WAF 检查却仍然未被授权。一个已登录用户也可能提交与防护规则匹配的输入。成功的身份验证、可接受的请求内容和被允许的操作是彼此独立的条件。

WAF 可以防护哪些内容？

WAF 可以帮助识别并限制与其已配置防护逻辑匹配的流量。常见规则类别涉及注入模式、协议异常以及可疑的请求内容。其防护范围取决于规则集、引擎、可见性以及应用程序的上下文。

WAF 无法仅通过通用的请求检查可靠地推断出所有业务不变量。一个看起来合法的操作仍然可能违反应用程序的授权规则。如果某个账户能够因为应用程序遗漏了权限检查而检索到另一个账户的私有对象，那么无论外围的流量控制如何，应用程序都需要补上该权限检查。

The OWASP 应用程序滥用类别 还要说明为何重复的有效操作会造成与格式错误的负载截然不同的问题。机器人策略、应用限制以及身份控制可以作为对 WAF 检查的有益补充。

将 WAF 视为循证防御中的一层。把应用修复工作纳入工程计划，审查暴露的接口，并验证 WAF 能接收到相关流量。被拦截的测试请求，是在该配置下对该请求本身的证据，而不是证明所有变体都已被覆盖。

业主应如何调查误报？

所有者应通过关联合法交易与其规则匹配、请求上下文以及最终执行操作来调查误报。目标是在不影响其他地方防护的前提下进行尽可能细致、局部的修正。

1. 捕获一个已清理的事件。 保留路线、时间窗口、请求标识符和用户可见的结果。避免不必要地复制凭证或已提交的个人数据。
2. 确认执法来源。 确定是 WAF、其他边缘策略，还是应用程序生成了此次拒绝。
3. 检查匹配条件。 查看触发该规则的字段和规范化内容。检查该输入是否符合此路由的预期。
4. 应用范围调整。 在合适的情况下，更倾向于进行特定路由或特定参数的更改。广泛地禁用某项规则可能会影响到无关的端点。
5. 验证正常和不期望的情况。 确认合法的工作流程正常运行，并且预期的防护措施仍然适用。

支持团队和工程团队应使用相同的事件标识符。“访问被拒绝”的屏幕截图可能有助于定位症状，但很少能解释具体规则。良好的关联可以缩短客户报告与相关交易证据之间的距离。

在收集工作流中应如何处理 WAF 响应？

在将页面视为源数据之前，采集工作流应先识别 WAF 或其他安全响应。状态码和成功完成的 HTML 解析并不能证明所需内容已被传送。

要求预期的实体和字段，然后识别登录、质询或明确拒绝等替代状态。将真实的空结果与不可用内容区分开来。如果你能控制来源，请为采集客户端提供有文档记录的访问路径和有意义的错误约定。

The Scrapeless Web Unlocker 文档 描述其基于 URL 的集合界面。 Web Unlocker 产品 可以针对许可的工作流进行评估，同时源的所有者仍然对访问策略负责。不要将技术检索等同于授权。

在评估成本时，请使用具有代表性的页面 无爬取方案定价。在衡量经验证的结果时，当某个页面未能满足你的契约时，要保留其对应的响应类别。相关的 动态浏览器集合工作流 提供实现上下文，由当前文档来规范支持的设置。

规划可维护的 WAF 部署

一个可维护的 WAF 部署应包括观测、审查，以及对例外情况的明确责任人。先从最重要的应用路由入手，并记录哪些团队可以更改强制执行行为。

练习那些容易被忽视的普通输入：国际化文本、长描述、结构化搜索过滤条件，以及应用程序可接收的与文件相关的元数据。通用攻击规则与这些输入的交互方式，可能会与对简单主页请求的处理方式不同。

随着应用行为的变化，重新审查例外情况。对旧路由来说必要的排除，在该路由退役后可能就会变成不必要的暴露。为每项调整保留其原因、范围和审查负责人，以便未来的运营人员判断它是否仍然适用。

结论

WAF 会检查 Web 事务并强制执行应用层流量策略。其价值取决于正确的部署位置、合适的规则以及对误报的谨慎处理。诊断实际的强制执行事件，使应用权限保持独立，并在采集管道接受返回内容之前先对其进行验证。