正则表达式拒绝服务攻击（ReDoS）是一个日益增长的风险。 现代应用安全随着越来越多的团队依赖输入验证和模式匹配，设计不佳的正则表达式可能会引入性能漏洞，攻击者可以利用这些漏洞来降低服务速度或导致服务中断。事实上， OWASP ReDoS 被描述为一种拒绝服务攻击，它利用了许多正则表达式实现速度极慢这一事实，有时运行时间会随着输入大小呈指数级增长。
同时，ReDoS攻击在云原生和分布式系统中尤其危险。 CI/CD在基于 Web 的环境中，API、网关或身份验证流程中单个易受攻击的正则表达式就可能大规模影响可用性。因此，团队应将 ReDoS 攻击视为真正的可用性风险，而不仅仅是少数特殊情况。
更重要的是，这些漏洞在开发过程中往往难以被发现，因为传统方法侧重于语法而非执行行为。因此，低效的正则表达式模式很容易在不触发任何警报的情况下投入生产环境。
这时，像 Xygeni 这样的现代应用安全平台就派上了用场。它们通过将安全检查直接嵌入到开发工作流程中，帮助尽早发现这些问题，并优先处理真正可控且影响巨大的风险，而不是仅仅制造更多的噪音。
什么是 ReDoS（正则表达式拒绝服务攻击）？
ReDoS（正则表达式拒绝服务）是一种漏洞，当正则表达式模式导致过度回溯时，就会发生这种漏洞，从而导致执行时间呈指数级增长。
简单来说，恶意输入会迫使你的应用程序花费大量时间来评估正则表达式，从而阻塞系统并降低性能。
例如，带有嵌套量词的模式如下：
(a+)+处理某些输入时可能会变得非常低效，尤其是当这些输入是攻击者故意构造的时候。
虽然这看起来像是一个极端情况，但在实际应用中却非常常见，尤其是在验证逻辑、表单输入和 API 请求处理中。
ReDoS攻击的工作原理
ReDoS攻击不需要高深的技术手段，而是利用正则表达式引擎可预测的行为。
灾难性的倒退
攻击者瞄准的是一个可以匹配多条路径的正则表达式。然后，他们提供输入，迫使引擎探索大部分或所有路径。
攻击者精心设计的输入
攻击者通常会发送：
- 包含重复字符的长字符串。
- 输入几乎完全匹配，但最后却失败了。
- 针对模式中最模糊部分的有效载荷。
性能下降
由于每次请求都会消耗 CPU 资源，因此这种影响会迅速累积：
- 终端延迟较高。
- 线程池耗尽。
- 单线程运行时中的事件循环停滞。
这些攻击不需要复杂的漏洞利用程序。相反，它们利用了低效的模式匹配机制，因此如果你的工具只检查语法或已知的CVE漏洞，就很难发现它们。
ReDoS漏洞在现实世界中的影响
ReDoS攻击了CIA三要素中的“A”：可用性。乍一看，它似乎只是稳定性问题，而非安全事件，但当你把所有线索串联起来后，就会发现问题所在。
API 速度变慢
单个使用易受攻击的正则表达式的端点可能会在输入验证、请求路由或身份验证检查期间造成 CPU 使用率飙升。
服务中断
在负载过高的情况下，ReDoS 热点会导致 pod 重启、自动扩缩容性能下降，并引发级联故障。
资源耗尽
ReDoS 可以消耗：
- 应用节点上的 CPU。
- 由于回溯状态而产生的内存。
- 阻塞其他请求的工作线程。
由于 ReDoS 攻击的目标是性能而非数据泄露，许多团队低估了其影响。然而，可用性是应用程序安全的核心组成部分，任何中断都可能迅速转化为业务风险。
重大变革才是真正的信任问题
当开发者说他们不信任自动修复功能时，他们通常指的是一件非常具体的事情：他们不相信自动修复功能不会破坏某些东西。
这种信任问题在依赖关系修复中表现得最为明显。
存在漏洞的软件包可能已有补丁版本，但这并不意味着升级就安全。补丁版本可能会移除应用程序使用的某个方法，可能会重命名某个 API，可能会加强类型约定，或者修改某些行为以通过单元测试但导致生产环境回归。在许多团队中，实际的修复成本并非在于应用补丁本身，而在于评估其影响范围。
考虑一个简单的 Java 示例。一个代码库依赖于一个库，该库中一个通用方法在 1.x 版本中存在，但在 2.x 版本中被移除。
现实世界中的 ReDoS 攻击和安全事件
ReDoS攻击并非仅仅是理论上的漏洞。它已经在实际应用中被利用，影响了广泛使用的库和生产系统。
以下是一些显著的例子，突显了低效正则表达式模式的影响：
Moment.js ReDoS漏洞
最著名的 ReDoS 漏洞之一受到影响 Moment.js一个广泛使用的 JavaScript 日期库。
- 设计不佳的正则表达式模式导致了过多的回溯。
- 攻击者可以通过精心构造的输入来触发高 CPU 使用率。
- 使用 Moment.js 的应用程序容易受到拒绝服务攻击。
这个问题表明，即使是受信任的库也可能给成千上万个应用程序引入性能漏洞。
Node.js 验证器库 (validator.js)
另一个例子涉及 验证器常用于输入验证。
- 某些验证函数依赖于效率低下的正则表达式
- 恶意输入可能会显著延迟执行。
- 这影响了依赖用户输入验证的 API 和后端服务。
由于 validator.js 被广泛使用，其影响波及多个应用程序和服务。
Cloudflare 服务中断（基于正则表达式的故障）
一起备受瞩目的事件涉及 Cloudflare其中，一个错误的正则表达式模式导致了一次重大故障。
- 生产环境中部署的正则表达式导致了 CPU 使用率过高。
- 全球系统均出现无响应情况。
- 互联网的大部分区域暂时受到影响
虽然这不是恶意攻击，但这一事件清楚地表明，正则表达式效率低下会在大规模情况下造成现实世界的后果。
为什么传统安全工具无法应对 ReDoS 系统
这是转换部分，因为它解释了大多数团队感受到的差距：扫描仪运行， dashboards 填充，但 ReDoS 仍然能够突破防线。
静态工具侧重于语法
许多扫描器可以标记“危险的正则表达式模式”，但它们通常缺乏信心来确定该模式在您的上下文中是否真的可被利用。
无执行上下文
ReDoS 关注的是运行时行为。OWASP 指出，许多正则表达式实现可能会出现极端情况，导致运行速度极慢，有时甚至与输入大小呈指数级关系。
如果一个工具从不考虑输入形状、匹配失败条件或执行路径，它就会错过风险或让你陷入大量的误报中。
未进行可利用性分析
正则表达式可能“理论上存在风险”，但在实践中却难以实现。反之，公共端点中一个“小型”验证器也可能引发真正的安全事件。缺乏上下文信息，团队要么忽略警报，要么过度修复。
传统扫描器通常无法检测到 ReDoS 攻击，因为它们不会评估正则表达式在运行时或恶意输入条件下的行为。而像 Xygeni 这样的平台通过将分析与……相结合，弥补了这一不足。 背景风险评估帮助团队了解弱点是否真的可改进且有影响。
如何检测ReDoS漏洞
可以通过结合设计规范和测试来检测ReDoS攻击。此外，还需要持续运行检查，而不仅仅是在安全审查期间运行。
安全的正则表达式设计
首先选择能最大限度减少歧义的模式。避免使用嵌套量词和重叠的选项。
模糊测试
使用以下命令测试正则表达式模式：
- 输入内容非常长。
- 差一点就成功的输入，但最终失败了。
- 重复标记旨在触发回溯。
静态分析
使用分析方法来标记已知的风险结构和模式，这些结构和模式与…… CWE-1333.
运行时验证
尽可能对输入长度进行限制，并对正则表达式求值设置超时时间。 OWASP的输入验证指南e 明确警告了 ReDoS 攻击，并强调了定义最小和最大输入长度的重要性。
诸如 Xygeni 之类的高级应用安全解决方案超越了模式检测的范畴。 在工作流上下文中分析代码 并帮助团队专注于在实际场景中最可能重要的问题，从而减少误报并加快补救速度。
如何防范ReDoS攻击
预防是更安全的模式、更安全的输入和更安全的运行时选择的组合。
避免使用嵌套量词
嵌套重复往往会造成最严重的回溯问题。
限制输入大小
这是最简单可靠的缓解措施。为通过正则表达式验证的输入设置最大长度限制。OWASP 强调长度限制是安全输入验证的关键组成部分。
尽可能使用安全的正则表达式引擎
如果可以选择引擎，最好选择设计用于避免灾难性回溯的引擎。 谷歌的 RE2 定位为回溯正则表达式引擎的安全替代方案。
使用分层检查验证输入
不要依赖单个正则表达式进行所有验证。应结合使用：
- 字符允许列表，
- 严格的长度检查，
- 每个字段的模式更简单。
防止ReDoS攻击需要安全的编码实践和 在整个开发生命周期中进行持续验证尤其是在应用程序规模扩大和依赖项增加的情况下。
Xygeni 如何帮助检测和预防 ReDoS 攻击
Xygeni 通过结合多层分析，帮助 DevSecOps 团队检测和预防 ReDoS 漏洞。
我们可以提供：
- 开发过程中易受攻击的正则表达式模式的检测
- 数据流和执行路径分析
- 识别可利用的漏洞，而不仅仅是理论上的漏洞。
- 融入 CI/CD pipeline用于连续扫描
- 为开发商提供可操作的补救指导
Xygeni 不会用大量警报淹没团队，而是优先处理以下事项： 实际可利用的漏洞 并且富有影响力。
这样一来，团队就能更快地解决实际问题，而不会减慢开发速度。
DevSecOps团队的最佳实践
左移安全
将 ReDoS 检查纳入与代码审查和单元测试相同的流程中。
自动扫描
对每一项运行检查 pull request 因此，正则表达式风险不会等待定期审查。
监视依赖项
正则表达式漏洞也可能出现在依赖项和输入解析库中，因此要严格遵守依赖项安全规范。
持续验证输入
在边缘应用长度限制和输入规则，然后在关键服务内部再次验证。
通过将安全性直接嵌入到开发工作流程中，团队可以在 ReDoS 等性能漏洞进入生产环境之前就加以预防。
ReDoS 防护始于无阴影的可见性
ReDoS攻击常常被忽视，但它会对应用程序的性能和可用性产生重大影响。OWASP将ReDoS定义为一种源于极端正则表达式运行时行为的拒绝服务风险。
这意味着你需要的不只是基本的扫描。你还需要上下文信息、优先级排序和自动化。
如果将正则表达式视为在攻击者控制的输入下可能失效的代码，就能更早地发现 ReDoS 攻击，从而构建更安全的系统。借助 Xygeni，团队可以减少干扰，优先处理真正的风险，并加强应用安全控制。 CI/CD 工作流程。
结语
ReDoS漏洞很容易引入，但如果没有正确的上下文很难检测出来。
传统工具侧重于识别问题，而现代应用安全则需要了解哪些漏洞才是真正重要的。
因此，为了保持领先地位，团队需要在整个开发生命周期中实现可见性、优先级排序和自动化协同工作。
这就是 Xygeni 的优势所在。它专注于可利用的风险，帮助团队更早地发现问题，减少干扰，并确保应用程序从开发到部署的整个过程安全无虞。
从根本上说，如今构建安全的软件意味着要超越简单的扫描，采用情境化的、实时的安全方法。
开始构建安全、可靠的应用程序 实时检测和上下文安全。
常见问题
什么是ReDoS攻击？
ReDoS（正则表达式拒绝服务）攻击是一种漏洞，攻击者可以利用低效的正则表达式模式导致处理时间过长，从而导致性能下降或应用程序崩溃。
为什么ReDoS在现代应用中存在危险？
ReDoS攻击会消耗CPU资源并降低服务速度，从而影响应用程序的可用性。在云原生环境中，这种情况会迅速升级为系统级的性能问题。
开发人员如何防范 ReDoS 漏洞？
开发者可以通过避免使用复杂的正则表达式模式、限制输入大小、使用安全的正则表达式引擎以及集成安全检查来防止ReDoS攻击。 CI/CD pipelines.
传统安全工具能否检测到ReDoS攻击？
大多数传统工具难以检测ReDoS攻击，因为它们不分析运行时行为或可利用性。高级应用安全解决方案通过评估代码在实际场景中的执行方式，提供更佳的检测效果。
Xygeni 如何帮助防止 ReDoS 攻击？
Xygeni 可检测易受攻击的正则表达式模式，分析执行路径，并对可利用的风险进行优先级排序。它集成到…… CI/CD pipeline并为开发商提供可操作的补救指导。
关于作者
联合创始人兼首席技术官
法蒂玛 Said 专注于面向开发者的应用安全、DevSecOps 和 software supply chain security她将复杂的安全信号转化为清晰、可操作的指导，帮助团队更快地确定优先级、减少干扰并交付更安全的代码。
