Cloudflare 发布 Application Profiles 以强制执行正向安全策略
Enforce positive security with Cloudflare Application Profiles
Cloudflare 推出了 Application Profiles 功能,通过分析 HTTP 请求的结构与格式来执行正向安全策略,并显著减小攻击面。
该功能现已向拥有 API Security 的客户开放,同时面向未购买该服务的 Enterprise 客户开放邀请制闭源测试。
原文介绍了该产品在验证流量结构时的运作方式,读者可以借此了解其处理应用层安全策略的具体实现。
今天,我们推出了应用程序配置文件,这是执行积极安全策略的无缝方式。通过分析 HTTP 请求的结构和格式并识别偏差,Cloudflare 可以帮助您显著降低攻击面。
我们与每位客户交谈时,他们都想知道我们如何保护他们免受使用前沿 AI 模型的攻击。这已成为任何从事安全工作的人们的首要任务。大型语言模型(LLMs)甚至让非技术人员也能通过一次提示发起攻击。LLMs 可以生成恶意负载,测试已知技术,并通过根据应用程序或 Web 应用防火墙(WAF)的反馈来变异其战术,自动探测应用程序。
我们的工具已改变,以保持领先攻击者一步。托管 WAF 规则和基于机器学习的检测仍然是检测 SQL 注入、跨站脚本、远程代码执行和新 CVE 等技术的关键,包括这些攻击的许多变体。答案不能仅仅是“更快修补”:这不可持续,如果您尚未完全映射漏洞,它也不起作用。
如果您可以通过分析流量结构来学习什么是良好请求会怎样?而不是仅仅寻找类似已知攻击的请求,我们可以只允许符合预期的请求。通过这样做,我们将大幅降低攻击面。例如,如果查询中的搜索字段不期望特殊字符,我们只能接受字母数字字符串。这已经可以防止大量已知攻击。
但我们不会止步于此。一旦我们学会了您的 HTTP 请求的结构和格式,我们就能推断每个操作的目标,然后了解应用程序最终的功能。有了这些信息,我们可以识别并优先处理最关键、最脆弱的操作和字段,先行加以关注。
Cloudflare 已通过 Schema Learning 和 Schema Validation 支持 API 的积极安全。我们现在通过 Application Schema Profiles 将此保护扩展到 Web 应用程序。您上线一个应用程序,我们学习其配置文件,然后开始部署始终开启的检测,识别不合规。全部自动化,并由强大的分析增强。
我们正在向未使用 API 安全的受邀企业客户开放封闭测试;已使用 API 安全的客户已可访问。
基于已学习的配置文件验证请求
Schema Profiles 会定期从观测流量中学习预期的请求结构。配置文件可用后,始终开启 的验证层会自动部署到实时流量。对于每个请求,检测会评估其是否符合配置文件,并将结果作为元数据添加,增强已关联到请求的信息。该信号本身不执行操作:客户可以在安全分析中分析过去流量,决定何处适合执行,并创建安全规则以阻止不合规请求。对没有配置文件的操作请求,该功能不进行分类。
与托管规则不同,验证失败不需要请求匹配已知攻击签名。超出预期范围的值、未知的枚举值、无效的通用唯一标识符(UUID)或意外字符——所有这些都可以被识别,因为它们与学习到的配置文件不同。
例如,考虑以下操作:
www.example.com/shop/2dbda2e7-cfc9-448d-9465-799d2e6ff363/inventory?product_id=938062541
下面我们描述学习过程,该过程仅评估请求的结构和格式。当观察到足够的流量后,我们会学习到路径期望一个 UUID 变量,并且 product_id 是一个整数以及它的边界。当 product_id 包含字符串时,它将被标记为违规。同样,Cloudflare 可以识别格式错误的 UUID 值,并且当客户启用强制执行时,阻止非 UUID 输入到达相应的处理程序。这些简单的过滤器减少了攻击者可以发送的输入范围,防止了绝大多数典型攻击向量,例如 SQL 注入、跨站脚本、远程代码执行等。
不符合并不总是意味着恶意。应用发布、新客户端或异常但有效的请求也可能引入差异。我们建议先以观察模式开始,以便客户在强制执行前审查配置文件的影响。
学习请求的预期结构
为了确定 Web 或 API 应用程序的预期请求结构,Schema Profiles 会定期分析观察到的流量。每个配置文件可能包含以下内容,具体取决于应用程序流量:
- 路径变量
- 查询参数
- 头部和 Cookie
- 正文结构(JSON 正文或表单编码)
对于每个字段,系统会学习其数据类型(整数、字符串、布尔值、数组、UUID 或枚举)以及诸如数值范围、短枚举、字符串长度和字符类别等约束。
学习适用于客户选择进行分析的操作。在 Web Assets 中,operation 是 Cloudflare 用来指代通过 HTTP 方法、主机名模式和路径模式识别的操作。Web Assets 持续发现操作,并在 Web Assets > Operations 下列出。客户也可以手动添加操作。对已发现的操作,分析不会自动启动,而手动创建的操作在创建时会触发分析。对于已发现的操作,客户必须有意从操作的溢出菜单中选择 Learn profile。
启用分析后,Cloudflare 收集符合条件的流量,并每周为每个区域自动运行学习,使用最近成功的流量。一个操作需要至少 1,000 次在过去七天内收到 2xx 响应的请求来学习字段,至少 10,000 次来学习数据边界。成功的请求可能包含机器人和扫描器,因此客户应在强制执行前审查已学习的配置文件。我们的路线图包括允许客户按需触发学习并排除自动化流量。
学习完成后,客户可以通过选择操作的 View details 并在 Security overview 面板中找到已学习的模式来查看配置文件。如果未显示已学习的模式,说明 Cloudflare 仍在为该配置文件收集数据。客户还可以将配置文件导出为 OpenAPI v3 模式文件。
学习到的配置文件会根据应用流量变化每周更新。新增字段会被添加,已不再观察到的字段会被移除,从而验证跟踪应用的变化。客户可以通过下载学习到的 schema 并上传到 Schema Validation 来固定并保存学习到的 schema。
在阻断前先审查
Security Analytics 现在新增了一个 Profile Analysis 选项卡。客户可以选择验证配置文件并查看流量趋势,包括过去七天内有多少请求不符合学习到的配置文件。
客户可以查看符合和不符合的流量。他们可以深入违规细节并查看采样日志,了解违规发生的位置、受影响的字段以及为何验证失败。违规被分为 十个原因,包括类型不匹配、值超出学习范围以及无效格式。
一旦团队了解影响,就可以使用 Security Rules 对信号采取行动。规则可以覆盖整个应用,也可以限定在选定的路径、操作或字段。团队可以控制监控位置和阻断位置。
面向 Web 与 API 流量的正向安全
传统 WAF 学习模式可以构建详细的正向安全策略,但通常需要运维人员审查建议、分阶段更改并维护策略实体。Cloudflare Schema Profiles 将验证暴露为请求字段 cf.schema_validation.learned.violated,允许客户将其与请求属性、Bot Score、Attack Score 以及其他信号合并到单个 Security Rule 中。通过创建简单规则,团队可以组合检测并精确定义 Cloudflare 何时采取行动。
还有两类字段可用于创建更有针对性的规则。首先是收集违规发生位置的字段。例如,基于我们的初始示例,如果 product_id 查询参数的值不符合配置文件,以下字段将被填充 cf.schema_validation.uploaded.query.violated_parameters = ["product_id"]。这使客户能够创建仅在特定字段上执行正向安全或将其排除在执行之外的规则。
第二类字段收集配置文件中不存在的新参数。当你想处理带有新参数的请求(例如部署应用的新版本)或通过阻止过去未检测或未定义的任何参数进一步限制姿态时,这非常有用。
使用案例 | 字段 | 位置值 | 示例 |
|---|---|---|---|
识别请求中违规发生的位置 |
|
|
|
识别请求中是否出现未声明的参数 |
|
|
|
即将推出:关键字段分析,帮助您部署正向安全
即使采用灵活的执行设计,客户仍告诉我们部署正向安全策略在操作上很复杂。大型应用可能拥有数千个操作和数万个字段,但并非所有操作和字段风险相同。情境化 与 优先级排序 帮助安全团队以受控且自信的方式推出正向安全。
大语言模型(LLM)可以帮助为学到的画像赋予上下文,从而提供额外的洞察。对于 Web 应用程序而言,路径和字段名称通常是不言自明的,因而具有语义。例如,我们尝试在四个随机应用程序的已学画像上运行托管于 Workers AI 的模型。该模型成功识别了两个系统应用程序中 clientId 和 account_number 之间的联系,以及使用一次性密码(OTP)增强身份验证的共同依赖关系。突显这一上下文使安全团队能够优先采取诸如配置速率限制规则(Rate Limiting Rules)等行动,以防范针对账户的暴力破解攻击。
这些由 LLM 驱动的洞察将直接在仪表板中显示,并与 Web Assets 中的每个操作并列呈现。在执行一键部署之前,团队可以评估旨在保护这些关键字段的规则推荐,并通过使用历史流量的缓解模拟来获得信心。
除了通过语义洞察和 risk indicators 为操作提供上下文之外,我们还在开发额外的指标,以便使用历史请求趋势和信号对操作进行排序。这使安全团队能够将缓解工作首先集中在最高优先级的操作上,包括:
- 数据丢失:异常增加的数据传输呈现上升趋势
- 侦察活动:未知参数数量庞大
- 业务关键性:流量总量与所服务的唯一 session IDs 相关联
现已推出的功能
由于这是 Schema Learning 和 Schema Validation 的延伸,拥有 API Security 的客户已经可以访问。我们正在向没有 API Security 的客户开放封闭测试,他们可以在生产 Web 应用程序流量上测试 Schema Profiles,与产品团队会面,并就画像准确性、分析和强制控制提供详细的反馈。访问权限通过邀请获得,并不意味着未来计划中的可用性。如果您不是 API Security 客户并希望获得访问权限,请联系您的客户团队。
该功能支持路径、查询参数、标头、Cookie、JSON 请求正文和表单编码的请求正文。画像可以验证整数、字符串、UUID、数组以及最多包含三个值的枚举。目前不支持多部分表单(Multipart forms)、GraphQL 和 XML。
当参数名称重复时,Schema Profiles 会验证每个值,但它们不强制参数唯一性。它们也不会学习和强制要求必需的参数,或者仅仅因为请求包含新参数而阻止该请求。
抢先应对零日漏洞
我们关于 Application Profiles 的构想并不止于验证请求结构。相同的工作流可以学习应用程序期望的其他特征(例如 ASN 或 JA4s),在流量偏离这些特征时进行解释,并让安全团队对定义“正常”状态充满信心。通过主动安全工作流,我们帮助安全团队抢先应对零日漏洞!
Source: cloudflare blog · blog.cloudflare.com