ReDoS 正则回溯型拒绝服务攻击原理与实战

导语：一条精心构造的字符串输入，配合一段看上去人畜无害的正则表达式，就能把服务器 CPU 拉满到 100%——这就是 ReDoS（正则表达式拒绝服务）。它不依赖漏洞，只依赖开发者写代码时的一个微小疏忽。这篇文章拆解它的原理、危险模式与实战打法。

一、原理：为什么正则会让 CPU 100%

正则引擎匹配失败时会回溯——它会撤销上一步的匹配，尝试新的组合。对大部分正则来说，回溯几次就能判断成功或失败。但当正则写成 ^(w+s?)*$ 这种嵌套量词形式时，回溯次数会指数级爆炸。

以简化版 ^(d+)*$ 匹配字符串 123456789z 为例：引擎要把 9 个数字分成若干段，每种切分方式都尝试一遍。结果是：

n=9：511 种组合
n=20：约 100 万种组合
n=30：约 10 亿种组合

字符每加一位，匹配时间指数级增长。一条 30 位的精心构造字符串，能把 V8 引擎打挂。服务端正则验证型接口中招，就是经典的 DoS。

二、危险正则的三大特征

实战中能打的 ReDoS 正则，都逃不开这三种构造：

嵌套量词：(a+)+、(w+s?)*，外层量词套内层量词是最大元凶
重叠字符类：(d|d+)、(w|.)*，多种匹配路径走同一条字符
贪婪 + 锚定失败：贪婪量词配 ^...$ 锚定，匹配失败时回溯代价最高

只需源码里出现上述任意一种模式，这个端点就有 ReDoS 的潜质。看几个真实代码里的高危模式：

// 手机号校验（危险）
/^(0|[1-9][0-9]*)+$/

// 邮箱校验（危险）
/^([a-zA-Z0-9]+)*@example.com$/

// URL 校验（危险）
/^(w+://)?[w.-]+(:d+)?(/.*)?$/

// 用户名校验（危险）
/^([a-zA-Z0-9_]+)*$/

对应的攻击 payload 也朴素：aaaaaaaaaaaaaaaaaaaa!、40 位字母末尾加一个非预期字符，就能把匹配时间从毫秒拉到分钟级。

三、多语言引擎的差异

不是所有正则引擎都会被 ReDoS 拿下。V8 引擎 8.8 之后、Google Chrome 88+、Python 3.11+ 引入了一部分防御机制，能识别部分灾难性回溯并提前终止。但Firefox 的 SpiderMonkey、Java 的 java.util.regex、PHP 的 PCRE、Ruby 的 Onigmo 至今仍是高危目标——尤其是 Java 服务端，PCRE 的贪婪回溯是默认行为。

测试时务必针对目标栈选择对应引擎：JVM 服务跑的是 PCRE，Node.js 是 V8，Python 3.11 以下是 backtracking 实现。跨语言通用的高危模式就那几个。