订阅以接收新文章的通知:

有害组合:微小迹象叠加可能会导致安全事件

2026-02-27

14 分钟阅读时间
这篇博文也有 English繁體中文版本。

凌晨 3 点,一个 IP 发出了登录页面请求。这看似无害。但随后,同一来源的多个主机和路径开始在请求中附加 ?debug=true,这是攻击者正在探测环境以评估技术栈并策划入侵的迹象。

一些细微的配置错误、被忽略的防火墙事件或请求异常单独来看似乎无害。然而,当这些微小迹象汇聚在一起时,可能会演变成被称为“有害组合”的安全事件。攻击者利用这些漏洞,发现并叠加许多细微问题(例如 Web 应用程序中遗留的调试标志,或未经身份验证的应用程序路径),以入侵系统或窃取数据。

Cloudflare 网络会观测对客户技术栈的请求,因此,在有害组合形成过程中,能够对这些迹象加以识别。在这篇博文中,我们将介绍 Cloudflare 如何从应用程序安全数据中发现这些迹象。我们将讨论最常见的有害组合类型及其带来的危险漏洞。我们还将详细介绍如何利用这些情报来识别并解决技术栈中的弱点。 

我们如何定义有害组合

可以采用几种不同的方式来定义“有害组合”,但我们将在本文中提供一种基于自身数据集的实用方法来定义。大多数网络攻击最终通过自动化来实现规模化;攻击者发现可行的漏洞利用后,通常会将其编写成脚本并植入机器人,以此来发起攻击。通过分析机器人流量、特定应用程序路径、请求异常和错误配置的交集,我们可以发现潜在的安全漏洞。我们利用这个框架来分析每秒数百万个请求。

虽然 Web 应用防火墙 (WAF)、机器人检测和 API 保护等单点防御措施已经发展到能够整合行为模式和声誉信号,但它们仍然主要侧重于评估单个请求的风险。相比之下,Cloudflare 看待“有害组合”检测的视角则转向更广泛的意图,通过分析围绕多个信号的上下文交集来识别正在酝酿之中的攻击事件。

基于上下文的有害组合检测

这种视角转变至关重要,因为许多真实的攻击事件没有明显的漏洞利用恶意有效负载、没有无害的签名,也没有直接表明这是一次“攻击”的单一事件。因此,下文中,我们将结合以下上下文构建几种潜在的有毒组合:

  • 机器人信号

  • 应用程序路径,尤其是各种敏感路径:管理、调试、指标、搜索、支付流程

  • 异常情况包括:意外的 http 代码、地理位置跳转、身份不匹配、ID 频繁变更、速率限制规避(多个分布式 IP 地址执行相同操作)、请求或成功率激增 

  • 漏洞或配置错误:缺少会话 cookie 或身份认证标头、可预测的标识符

我们查看了 Cloudflare 24 小时数据,以了解这些模式在热门应用程序技术栈中实际出现的频率。如下表所示,我们分析的主机中约有 11% 的主机易受此类有害组合的攻击,但易受攻击的 WordPress 网站导致分析失真。如果排除 WordPress 网站,则只有 0.25% 的主机显示了可利用的有毒组合的迹象。虽然这个比例极少,但它们代表容易容易遭到入侵的主机。

为了理解数据,我们将一次攻击过程划分为三个阶段:

  • 估算已探测的主机:这是“广撒网”的阶段。它会计算针对特定敏感路径(例如 /wp-admin)的 HTTP 请求所对应的唯一主机。

  • 估算按有害组合筛选的主机:在这个阶段,我们将主机清单缩小到符合我们定义的有害组合标准的特定主机。

  • 估算可访问的主机:成功响应了漏洞利用尝试的唯一主机,这是攻击的“确凿证据”。简单的 200 OK 响应(例如,通过附加 ?debug=true 触发的响应)可能是误报。我们对路径进行了验证,以过滤各种原因引起的干扰:即使状态代码为 200 也需要凭据的已验证路径;掩盖真实漏洞利用路径的重定向;以及为无法访问的路径提供成功代码的源配置错误。

在下几节中,我们将深入探讨这些具体发现及其背后的逻辑驱动因素。提供的检测查询是必要的,但如果不进行可访问性测试,则不足以得出确切的结果;因为检测结果可能是误报。在某些情况下,Cloudflare Log Explorer 支持对未采样的 Cloudflare 日志执行这些查询。

表 1.有害组合摘要

探测跨多个应用程序主机的敏感管理端点

我们检测到了什么?

我们观察到自动化工具扫描了常见的管理员登录页面,例如 WordPress 管理面板 (/wp-admin)、数据库管理器,以及服务器仪表板。Cloudflare Log Explorer 中执行的模板化查询版本如下所示:

SELECT
  clientRequestHTTPHost,
  COUNT(*) AS request_count
FROM
  http_requests 
WHERE
  timestamp >= '{{START_DATE}}'
  AND timestamp <= '{{END_DATE}}'
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '{{PATH_PATTERN}}' //e.g. '%/wp-admin/%'
  AND NOT match( extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$') // comment this line for Cloudflare Log Explorer
  AND botScore < {{BOT_THRESHOLD}} // we used botScore < 30
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

为什么这个问题很严重?

可公开访问的管理面板可能会让攻击者能够发起暴力破解攻击。如果成功,攻击者可能通过将面板添加到僵尸网络来进一步入侵主机,而僵尸网络会探测其他网站是否存在类似的漏洞。此外,这种有毒组合可能会导致:

  • 漏洞利用扫描:攻击者会识别您正在运行的特定软件版本(例如 Tomcat 或 WordPress),并针对已知漏洞 (CVE) 发起有针对性的漏洞利用攻击。

  • 用户枚举:许多管理面板会意外泄露有效的用户名,这有助于攻击者精心策划更具有说服力的网络钓鱼或登录攻击。

有哪些证据支持?

机器人自动化与暴露的管理接口的有害组合,例如:/wp-admin//admin//administrator//actuator/*/_search//phpmyadmin//manager/html//app/kibana/

要素

Signal

描述

机器人活动

机器人分数 < 30

漏洞扫描程序的典型机器人签名

异常

重复探测

对管理端点的异常访问

漏洞

可公开访问的端点

对管理端点的成功请求

如何缓解这个问题?

  1. 实施 Zero Trust 访问 

  2. 如果由于任何原因端点必须保持公开,请部署一个质询平台,以增加机器人的访问难度

  3. 实施 IP 允许列表:使用 WAF 或服务器配置,确保只能通过贵公司 VPN 或特定办公室 IP 地址才能访问管理路径。

  4. 隐藏管理路径:如果贵公司的平台允许,则重命名默认的管理 URL(例如,将 /wp-admin 更改为难以猜测的唯一字符串)。

  5. 部署地理位置屏蔽:如果管理员仅从特定国家/地区执行操作,请屏蔽这些区域以外流向这些敏感路径的流量。

  6. 强制执行多因素身份验证 (MFA):确保每个管理入口点都需要验证第二个因素;仅依靠密码不足以阻止专用爬网程序。

未经身份验证的公共 API 端点,放任通过可预测的标识符大规模泄露数据

我们检测到了什么?

我们发现了一些 API 端点,互联网上的任何用户无需密码或登录即可访问(请参阅 OWASP: API2:2023 - 失效的身份验证)。更糟糕的是,它识别记录的方式(使用简单、可预测的 ID 号,请参阅 OWASP: API1:2023 - 失效的对象级授权)让任何用户都可以轻松地“计算”您的数据库数量,从而使攻击者无需直接访问您的网站即可枚举并“抓取”业务记录。

SELECT
  uniqExact(clientRequestHTTPHost) AS unique_host_count
FROM  http_requests
WHERE timestamp >= '2026-02-13'
  AND timestamp <= '2026-02-14'
  AND edgeResponseStatus = 200
  AND bmScore < 30
  AND (
       match(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'),  '^[0-9]{3,10}$')
    OR match(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)'), '^[0-9]{3,10}$')
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'))  BETWEEN 3 AND 8
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)')) BETWEEN 3 AND 8
  )

为什么这个问题很严重?

这是一个“零利用”漏洞,也就是说,攻击者无需是黑客即可窃取您的数据;他们只需更改 Web 链接中的某个数字即可。这会导致:

  • 大规模数据泄露:大规模抓取您的整个客户数据集。

  • 二次攻击:被盗数据用于针对性网络钓鱼或帐户接管。

  • 监管风险:因泄露敏感的个人可识别信息 (PII),可能严重违反隐私条例 (GDPR/CCPA) 的规定。

  • 欺诈:竞争对手或恶意行为者可能获取您的业务量和客户群信息。

有哪些证据支持?

缺少安全控制措施与针对特定 API 端点的自动化攻击的有害组合。

要素

Signal

描述

机器人活动

机器人分数 < 30

来自单个客户端指纹的大量请求,通过不同的 ID 迭代。

异常

tid 基数高

单个访客在短时间内访问数百或数千个唯一资源 ID。

异常

稳定的响应大小

JSON 结构和文件大小一致,这表明每个猜测的 ID 都成功检索到数据。

漏洞

缺少身份验证信号

请求完全没有会话 cookie、Bearer 令牌或 Authorization 标头。

错误配置

可预测的标识符

tid 参数使用低熵、可预测的整数(例如,1001、1002、1003)。

查询核实了机器人分数和可预测的标识符,同时也在与查询匹配的流量样本中测试了高基数、稳定的响应大小和缺少身份验证等信号。

如何缓解这个问题?

  1. 强制执行身份验证:立即要求受影响端点提供有效的会话或 API 密钥。禁止匿名访问包含个人可识别信息或商业机密的数据。

  2. 实施授权(IDOR 检查):确保后端核实已执行身份验证的用户是否确实拥有查看其请求的 tid 的权限。

  3. 使用 UUID:将可预测的连续整数 ID 替换为长随机字符串 (UUID),使用户无法通过计算“猜中”标识符。

  4. 部署 API Shield:启用 Cloudflare API Shield,它提供架构验证(用于阻止意外输入)和 BOLA 检测等功能。

调试参数探测泄露系统详细信息

我们检测到了什么?

我们发现了攻击者将 debug=true 附加到网络路径来泄露系统详细信息的证据。Cloudflare Log Explorer 中执行的模板化查询版本如下所示:

SELECT
  clientRequestHTTPHost,
  COUNT(rayId) AS request_count
FROM
  http_requests
WHERE
  timestamp >= '{{START_TIMESTAMP}}'
  AND timestamp < '{{END_TIMESTAMP}}'
  AND edgeResponseStatus = 200
  AND clientRequestQuery LIKE '%debug=false%'
  AND botScore < {{BOT_THRESHOLD}}
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

为什么这个问题很严重?

虽然这不会立即窃取数据,但它为攻击者提供了您的内部基础设施的高清地图。这种“侦察”模式会显著提高攻击者下一次攻击的成功率,因为他们能够看到:

  • 隐藏的数据字段:不应向用户显示的敏感内部信息。

  • 技术栈详细信息:特定的软件版本和服务器类型,让攻击者能够查找这些版本的已知漏洞。

  • 逻辑提示:准确阐述代码工作原理的错误消息或技术栈跟踪,帮助攻击者找到破解代码的方法。

有哪些证据支持?

自动探测与针对多个主机和应用程序路径的错误配置诊断标志的有害组合。

要素

Signal

描述

机器人活动

机器人分数 < 30

漏洞扫描程序活动

异常

响应大小增加

切换调试标记时数据量出现显著跳跃,这表明正在泄露详细信息或技术栈跟踪。根据需要,添加以下这些附加条件:

选择

AVG(edgeResponseBytes) AS avg_payload_size、 

其中

edgeResponseBytes > {{your baseline response size}}

异常

重复的路径探测

跨不同端点(例如 /api、/login、/search)发送快速请求,专门测试相同的诊断触发器。根据需要,添加以下这些条件: SELECT

APPROX_DISTINCT(clientRequestPath) AS unique_endpoints_tested 

HAVING 

unique_endpoints_tested > 1

错误配置

允许的调试参数

生产环境 URL 中存在会更改应用程序行为的“debug”、“test”或“dev”标记。

漏洞

模式泄露

出现仅供内部使用的 JSON 字段或“firebase.json”格式的转储文件,这些文件会暴露底层结构。从而揭示了底层结构。

查询检查了机器人分数和带有调试参数的路径,同时也在与查询匹配的流量样本中测试了重复的探测、响应大小和模式泄露等信号。

如何缓解这个问题?

  1. 禁用生产环境中的调试:确保在生产部署配置中将所有“debug”或“development”环境变量严格设置为 false

  2. 在边缘过滤参数:使用 WAF 或 API 网关,在已知的调试参数(例如 ?debug=?test=?trace=)到达应用程序服务器之前将其剔除。

  3. 清理错误响应:配置 Web 服务器(Nginx、Apache 等)以显示通用错误页面,而不是显示详细的技术栈跟踪或内部系统消息。

  4. 审核 firebase/DB 规则:如果使用 Firebase 或类似的 NoSQL 数据库,请确保通过严格的安全规则限制对 /.json 路径的访问,以防止公共用户转储整个数据库模式或数据。

公开监测端点提供内部基础设施可见性

我们检测到了什么?

我们发现了“运行状况检查”和监测仪表板对整个互联网可见。具体而言,/actuator/metrics 等路径会响应任何提问的用户。Cloudflare Log Explorer 中执行的模板化查询版本如下所示:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // an example
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

为什么这个问题很严重?

虽然这些端点通常不会直接泄露客户密码,但却为复杂攻击提供了“蓝图”。暴露这些端点会导致:

  • 战略时机选择:攻击者可以实时监测您的 CPU 和内存使用情况,在系统已经不堪重负的情况下发动拒绝服务 (DoS) 攻击

  • 基础设施映射:这些日志通常会泄露内部服务的名称、依赖项和版本号,帮助攻击者找到已知的漏洞并加以利用。

  • 漏洞利用链接:有关线程计数和环境提示的信息,可用于绕过安全层或提升网络权限。

有哪些证据支持?

访问控制配置错误与针对 Asset/Path: /actuator/metrics, /actuator/prometheus, and /health 的自动化侦察的有害组合。

要素

Signal

描述

机器人活动

机器人分数 < 30

自动扫描工具系统地检查特定路径

异常

监测指纹

响应正文与已知的格式(Prometheus、Micrometer 或 Spring Boot)匹配,证实系统正在泄漏实时数据。

异常

HTTP 200 状态

成功从理想情况下本应向公众返回 403 Forbidden 或 404 Not Found 的端点检索到数据。

错误配置

公共监测路径

仅供内部使用的端点(例如 /actuator/*)可供用户公开访问,这些端点原本用于私密的观测。

漏洞

缺少身份验证

无需会话令牌、API 密钥或基于 IP 的限制,即可访问这些端点。

如何缓解这个问题?

  1. 通过 WAF 限制访问:立即创建防火墙规则,以阻止任何包含 /actuator//prometheus 的路径的外部流量请求。

  2. 绑定到本地主机:重新配置应用程序框架,使其仅在 localhost (127.0.0.1) 或私有管理网络上为这些监测端点提供服务。

  3. 强制执行基本身份验证:如果必须通过 Web 访问这些端点,请确保它们受到强身份验证(至少是复杂的基本身份验证或 mTLS)的保护。

  4. 禁用不必要的端点:在 Spring Boot 或类似框架中,禁用并非生产环境监测所必需的“Actuator”功能。

未经身份验证的搜索端点,允许直接转储索引

我们检测到了什么?

通常仅供内部使用的搜索端点(例如 Elasticsearch 或 OpenSearch)现在对公众完全开放。模板化查询如下所示:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/\_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$')
GROUP BY
  clientRequestHTTPHost

为什么这个问题很严重?

这是一个非常严重的漏洞,因为它无需任何技术技能即可利用,但造成的破坏却相当严重:

  • 大规模数据窃取:攻击者可以“转储”整个索引,在几分钟内窃取数百万条记录。

  • 内部侦察:通过查看“索引”(您存储内容的列表),攻击者可以识别网络中的其他高价值目标。

  • 数据破坏:根据配置的不同,攻击者不仅会读取数据,而且还可能修改或删除整个搜索索引,从而导致大规模服务中断。

有哪些证据支持?

我们看到了错误配置的暴露与针对  /_search, /_cat/indices, and /_cluster/health 的自动化流量和数据枚举的有害组合。

要素

Signal

描述

机器人活动

机器人分数 < 30

高速自动化签名尝试对大型数据集进行分页并“抓取”整个索引。

异常

意外响应大小

JSON 响应体积庞大,符合批量数据检索的特征而非简单的状态检查。

异常

重复的查询模式

系统“枚举”行为,攻击者循环遍历每一个可能的索引名称以查找敏感数据。

漏洞

/_search 或 /_cat/ 模式

直接暴露管理和查询级路径,而这些路径绝不应通过公共 URL 访问。

错误配置

HTTP 200 状态

端点主动响应来自未经授权的外部 IP 的请求,而不是在网络层或应用层拒绝这些请求。

查询检查了机器人分数和路径,同时也在与查询匹配的流量样本中测试了重复的查询模式、响应大小和模式泄露等信号。 

如何缓解这个问题?

  1. 限制网络访问:立即更新防火墙/安全组,以确保只能从特定的内部 IP 地址访问搜索端口(例如 9200、9300)和路径。

  2. 启用身份验证:为搜索集群启用“安全”功能(例如 Shield 或 Search Guard),要求每一次 API 调用都提供有效凭据。

  3. WAF 拦截:部署 WAF 规则以立即阻止来自公共互联网的任何包含 /_search/_cat/_cluster 的请求。

  4. 审核数据丢失:检查数据库日志,以了解来自未知 IP 的大量“Scroll”或“Search”查询,从而确定究竟泄露了多少数据。

成功尝试针对应用程序路径的 SQL 注入 

我们检测到了什么?

我们已经识别了攻击者发送的恶意请求,具体而言是旨在欺骗数据库的 SQL 注入Cloudflare Log Explorer 中执行的模板化查询版本如下所示:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

为什么这个问题很严重?

这是数据泄露的“隐蔽途径”。由于系统返回了成功状态代码 (HTTP 200),因此,这些攻击通常与合法流量混合在一起。如果不加以处理,攻击者可以:

  • 优化方法:通过反复试验,找到能够绕过过滤器的确切恶意有效负载。

  • 外泄数据:使数据库内容缓慢地外流,或泄露 URL 中传递的敏感信息(例如 API 密钥)。

  • 保持隐蔽:大多数自动化警报会查找“已被拒绝”的攻击尝试;“成功的”漏洞利用在海量的日志记录中更难发现。

有哪些证据支持?

我们看到了针对许多应用程序路径的自动化机器人信号、异常情况以及应用层漏洞的有害组合。

要素

Signal

描述

机器人

机器人分数 < 30

自动化流量的可能性较高;签名和计时与漏洞利用脚本一致。

异常

敏感路径中的 HTTP 200

来自本应触发 WAF 拦截的登录端点的成功响应。

异常

重复突变

同一请求的高频变化,表明攻击者在不断“调整”其恶意有效负载。

漏洞

可疑的查询模式

使用 SLEEP 命令和基于时间的模式,探测数据库的响应能力。

如何缓解这个问题?

  1. 立即进行虚拟修补:更新 WAF 规则,以专门阻止已识别的 SQL 模式(例如,基于时间的探测)。

  2. 清理输入:检查此路径的后端代码,确保其使用预处理语句或参数化查询。

  3. 补救密钥泄露:将所有敏感数据从 URL 参数移至请求正文或标头。轮换任何标记为“已泄露”的密钥。

  4. 审计日志:检查数据库日志,查找“HTTP 200”响应的时间范围,以确认是否成功提取了任何数据。

支付流程中的有害组合示例

信用卡测试和信用卡盗刷是最常见的欺诈手段之一。攻击者可能从暗网上购买大量信用卡。然后,为了验证有多少张卡仍然有效,他们可能会在网站上通过进行小额交易来测试这些卡。一旦验证成功,他们可能会使用这些信用卡在热门购物网站上购买商品,例如礼品卡。

支付流程中的疑似信用卡测试

我们检测到了什么?

在支付流程(/payment/checkout/cart)中,我们发现一天之中的某些时段,机器人每小时的请求量或每小时的支付成功率比过去 30 天的每小时基线值高出 3 个标准差。这可能与信用卡测试有关,攻击者试图验证大量被盗的信用卡。当然,营销活动也可能导致请求量激增,而支付服务中断则可能导致成功率骤降。

为什么这个问题很严重?

在没有营销活动、支付服务中断或其他因素影响的情况下,支付成功率下降与请求量激增同时发生,这可能意味着机器人正在进行大规模的信用卡测试。

有哪些证据支持?

我们针对 /payment/checkout/cart 使用了机器人信号与异常情况组合:

要素

Signal

描述

机器人

机器人分数 < 30

自动化流量的可能性很高,而非人为错误

异常

请求量 Z 分数 > 3.0,根据过去 30 天内指定小时的请求量基线计算,并按小时进行评估。这也考虑了每日季节性因素。

规模事件:攻击者正在测试一批信用卡

异常

成功率 Z > 3.0,根据过去 30 天内指定小时的成功率基线计算,并按小时进行评估。这也考虑了每日季节性因素。 

成功率突然下降可能意味着信用卡遭到拒绝,因为此类信用卡已被报告丢失或被盗

如何缓解这个问题?

对支付路径上所有机器人分数低于 30 的请求,使用 30 天支付路径的每小时请求量基准作为每小时速率限制。  

支付流程中的疑似信用卡盗刷

我们检测到了什么?

在支付流程(/payment/checkout/cart)中,我们发现一天之中的某些时段,来自人类(或假冒真人的机器人)的每小时请求量或每小时支付成功率比过去 30 天的每小时基线值高出 3 个标准差。这可能与信用卡盗刷有关,攻击者(可能是真人用户或假冒真人的机器人)尝试使用有效但被盗的信用卡购买商品。当然,营销活动也可能导致请求量和成功率激增,因此,来自特定 IP 地址的典型支付请求形式的额外上下文是必不可少的信息,如图所示。

为什么这个问题很严重?

在没有营销活动、支付服务中断或其他因素影响的情况下,支付成功率激增与请求量激增以及每个 IP 地址的高密度请求同时出现,这可能意味着真人用户(或假冒真人的机器人)正在进行欺诈性购买。这种情况下的每一笔成功交易都可能导致直接的收入损失或潜在的退款。

有哪些证据支持?

我们针对 /payment/checkout/cart 使用了机器人信号与异常情况组合:

要素

Signal

描述

机器人

机器人分数 >= 30

预计真人流量将大幅增加,且允许交易

异常

流量 Z 分数 > 3.0,根据过去 30 天内指定小时的请求量基线计算,并按小时进行评估。这也考虑了每日季节性因素。

攻击者的购物频率远高于普通顾客

异常

成功率 Z > 3.0,根据过去 30 天内指定小时的成功率基线计算,并按小时进行评估。这也考虑了每日季节性因素。

成功率突然飙升,可能意味着有效的信用卡已获授权可以购买

异常

IP 密度 > 5,根据指定小时内每个 IP 的支付请求数除以过去 30 天该小时内的平均支付请求数计算

过去 30 天内购物次数是普通顾客 5 倍的“真人”用户,这是一个危险信号

异常

JA4 多样性 < 0.1,根据指定小时内每个支付请求的 JA4 计算

JA4 账户的每小时购物次数异常,很可能是假冒真人的机器人

如何缓解这个问题?

基于身份的速率限制:利用 IP 密度,对支付端点上机器人分数 ≥ 30 的请求实施速率限制。

监测成功率:当支付端点上机器人分数 >=30 的“真人”流量成功率比其 30 天基线值高出 3 个标准差时,发出警报。

提出质询:如果某个高机器人分数请求(可能是真人)在 10 分钟内访问支付流程超过 3 次,则触发质询以降低其访问频率。

下一步:仪表板中的检测功能与 AI 驱动的补救措施

目前我们正在努力将这些“有害组合”检测结果直接集成到安全见解仪表板中,以便用户能够即时查看和了解此类风险。我们的路线图包括构建 AI 辅助的修复路径,届时仪表板不仅会显示有害组合,还会提出具体的 WAF 规则或 API Shield 配置,以消除此类组合带来的威胁。

我们诚邀您体验 Cloudflare 安全见解中新增的“有害组合”检测功能。单击此处即可加入候补名单

我们保护整个企业网络,帮助客户高效构建互联网规模的应用程序,加速任何网站或互联网应用程序抵御 DDoS 攻击,防止黑客入侵,并能协助您实现 Zero Trust 的过程

从任何设备访问 1.1.1.1,以开始使用我们的免费应用程序,帮助您更快、更安全地访问互联网。要进一步了解我们帮助构建更美好互联网的使命,请从这里开始。如果您正在寻找新的职业方向,请查看我们的空缺职位
应用程序安全

在 X 上关注

Himanshu Anand|@anand_himanshu
Cloudflare|@cloudflare

相关帖子