1. 项目概述当“高效”的正则变成“拒绝服务”的武器在Java开发中正则表达式是我们处理字符串匹配、验证和提取的“瑞士军刀”。无论是验证用户输入的邮箱格式还是从日志文件中提取特定字段正则表达式都以其强大的表现力让我们用一行代码就能完成复杂的文本处理任务。然而这把“军刀”如果使用不当尤其是当正则表达式遭遇精心构造的恶意输入时它就可能从高效的工具瞬间转变为拖垮整个应用性能的“性能炸弹”甚至引发“正则表达式拒绝服务”攻击也就是我们常说的ReDos。这个问题在面试中经常被提及也是Java八股文里关于安全与性能的经典考点。简单来说ReDos攻击的原理就是利用了某些正则表达式引擎包括Java内置的java.util.regex包在匹配过程中的“回溯”机制。攻击者提供一个特殊的、看似无害的字符串这个字符串会让正则引擎陷入近乎无限的计算循环中疯狂消耗CPU资源导致应用线程被长时间占用无法响应其他请求最终使得服务不可用。对于Web应用而言这可能意味着登录接口、搜索接口或任何涉及用户输入校验的地方都成了潜在的攻击入口。理解ReDos不仅仅是背下一个面试题的答案更是每一位Java开发者编写健壮、安全代码的必备素养。它连接着Java基础、性能调优和安全编码三个关键领域。接下来我将以一个资深开发者的视角带你彻底拆解ReDos的成因、在Java中的具体表现、如何亲手构造和复现攻击以及最重要的——如何在日常编码中有效防御。2. 核心原理拆解回溯机制是如何被“卡住”的要理解ReDos我们必须深入到Java正则引擎java.util.regex.Pattern的匹配原理中去。Java使用的是一种称为“回溯型NFA”的引擎。它的工作方式很像一个探险家在字符串和正则表达式的“迷宫”里尝试所有可能的路径直到找到一条能走通的。2.1 回溯正则引擎的“试错”本能回溯是这种引擎的核心机制。当正则表达式中有量词如*,,?,{m,n}或者选择分支|时引擎在匹配过程中会记录多个“备选状态”。如果当前选择的路径走不通它会退回到上一个记录点尝试另一条路径。这个过程就叫回溯。举个例子正则表达式ab去匹配字符串aaab是贪婪匹配引擎会先尝试匹配尽可能多的a于是它吃掉了所有的aaa。然后它发现下一个字符是b和正则式里的b匹配成功。匹配结束非常顺利几乎没有回溯。但如果匹配aaac呢同样贪婪的吃掉了所有aaa。引擎发现下一个字符是c和b不匹配。这时引擎开始回溯它会把最后一个a“吐出来”看看用aa去匹配a剩下的ab去匹配b行不行。字符串剩下aca匹配ac不匹配b。继续回溯再“吐”出一个a用a匹配a剩下aaca匹配ac不匹配b。继续回溯直到a匹配了0个a即不匹配任何字符然后试图用字符串开头的a去匹配b失败。至此所有可能性尝试完毕宣告匹配失败。你可以看到即使在这个简单的例子里一次失败的匹配也引发了多次回溯。在正常情况下这微不足道。但问题就出在某些正则模式会让回溯的次数呈指数级爆炸。2.2 灾难性的组合嵌套量词与重叠匹配导致ReDos的“罪魁祸首”通常是两种模式的结合嵌套的量词比如(a)。外层和内层相互作用为同一个字符串片段创造了海量的、重复的匹配可能性。重叠的匹配路径比如(a|aa)。字符串aaa可以被拆分成(a)(a)(a)也可以拆分成(aa)(a)或(a)(aa)。这又创造了多种组合。当这样的正则表达式去匹配一个恰好不匹配的字符串时灾难就发生了。引擎会孜孜不倦地尝试所有可能的组合方式直到穷尽所有可能性才肯罢休。而组合的可能性会随着字符串长度的增加而呈指数级增长。2.3 Java中的经典“杀手”正则让我们看一个Java里臭名昭著的例子^(a)$。这个正则的本意是验证字符串是否由一个或多个a组成。^和$表示从头到尾匹配。(a)是嵌套量词内层a匹配一个或多个a外层表示这个分组可以重复一次或多次。现在我们用这个正则去匹配一个非全部由a组成的长字符串比如aaaaaaaaaX9个a加一个X。匹配过程会变成一场计算灾难引擎首先用内层a贪婪地匹配掉所有9个a。然后它遇到X发现不符合a于是内层a开始回溯吐出最后一个a现在内层匹配了8个a。外层尝试进行第二次分组匹配用剩下的aX去匹配内层a。a匹配成功遇到X失败。内层再次回溯吐出a现在第二次分组匹配了0个a失败。外层回溯调整第一次分组的大小……引擎会尝试所有可能的分割方式第一次分组匹配9个a、8个a、7个a……直到0个a并对每一种分割再尝试对剩余字符串进行同样的嵌套匹配尝试。对于长度为n的字符串其回溯尝试的次数可以达到O(2^n)级别。当n30时回溯次数可能达到十亿次当n100时所需的计算时间对于任何现代服务器都是不可接受的。你的Java应用线程会卡在这一行String.matches(“^(a)$”)代码上CPU使用率飙升到100%而这就是一次成功的ReDos攻击。注意不仅仅是(a)类似(a*)*,(a|a?),(a|aa)*等模式都具有相同的危险性。核心特征是存在模糊的、可导致指数级回溯的匹配路径。3. 实战复现在Java中亲手触发一次ReDos理解了原理我们最好亲手“引爆”一次感受其威力。我们将编写一个简单的Java程序来模拟攻击。请注意此实验仅用于学习目的请在隔离的测试环境中进行切勿在生产环境或他人服务器上尝试。3.1 构建攻击演示程序import java.util.regex.Pattern; import java.util.regex.Matcher; public class ReDosDemo { // 危险的正则表达式 private static final String DANGEROUS_PATTERN ^(a)$; // 安全的等价正则表达式用于对比 private static final String SAFE_PATTERN ^a$; public static void main(String[] args) { // 构造恶意输入由大量a和一个破坏字符X组成 StringBuilder sb new StringBuilder(); for (int i 0; i 30; i) { // 尝试不同长度10, 20, 30 sb.append(a); } String maliciousInput sb.append(X).toString(); // 例如 aaaaaaaaaa...aX System.out.println(测试输入字符串长度: maliciousInput.length()); System.out.println(输入样例前20字符: maliciousInput.substring(0, Math.min(20, maliciousInput.length())) ...); // 测试危险正则 System.out.println(\n--- 开始测试危险正则 (^(a)$) ---); long startTime System.nanoTime(); try { boolean isMatch maliciousInput.matches(DANGEROUS_PATTERN); long endTime System.nanoTime(); System.out.println(匹配结果: isMatch); System.out.println(耗时: (endTime - startTime) / 1_000_000 毫秒); } catch (StackOverflowError e) { System.err.println(发生栈溢出错误正则引擎回溯过深。); } // 等待一下让CPU冷静 try { Thread.sleep(1000); } catch (InterruptedException e) {} // 测试安全正则作为对比 System.out.println(\n--- 开始测试安全正则 (^a$) ---); startTime System.nanoTime(); boolean isMatchSafe maliciousInput.matches(SAFE_PATTERN); long endTime System.nanoTime(); System.out.println(匹配结果: isMatchSafe); System.out.println(耗时: (endTime - startTime) / 1_000 微秒 (请注意单位是微秒)); } }3.2 运行观察与结果分析你可以逐步增加循环中的i值比如从10开始到20再到30来运行这个程序。当 i10可能耗时几十或几百毫秒已经能感觉到延迟。当 i20耗时可能会达到几秒甚至十几秒程序看起来像“卡住”了。当 i30 或更高在普通开发机上程序很可能在超时如果你没设置超时之前就运行了极长时间或者直接抛出StackOverflowError。而使用安全正则^a$的对比测试无论字符串多长匹配都会在微秒级内完成因为它没有嵌套量词匹配路径是线性的失败时几乎不产生回溯。实操心得不要在生产环境做这个测试即使在你自己的开发机上当输入长度超过25时也可能会导致IDE无响应。最好在命令行中运行并做好随时用CtrlC中断的准备。观察系统监控运行测试时打开系统任务管理器或top命令你会看到运行该Java进程的CPU核心使用率瞬间飙到100%这是ReDos攻击最直观的外部表现。理解“失败匹配”是关键ReDos攻击总是发生在匹配失败的场景下。如果输入是纯aaaaaaaaaa即使使用危险正则匹配也会很快成功因为引擎一旦找到一条成功路径就会停止。攻击的精髓就在于那个末尾的X它确保了匹配必定失败从而迫使引擎遍历所有可能的失败路径。4. 防御策略编写免疫ReDos的Java正则表达式知道了危害我们更关心如何避免。防御ReDos需要从编码习惯、工具使用和架构设计多个层面入手。4.1 编写“确定性”正则表达式这是最根本的解决方法。避免编写具有模糊匹配路径和指数级回溯风险的正则。避免嵌套的量词(a)、(a*)*、(a?)是绝对的禁区。需要匹配多个重复单元时思考是否可以用一个量词解决。例如^(a)$的安全等价形式就是^a$。警惕重叠选项类似(a|aa)、(a|ab)这样的模式对于字符串aaaa|aa提供了多种划分方式。应尽可能简化分支条件使其互斥。使用占有型量词或原子分组如果引擎支持Java正则支持占有型量词*,,?,{m,n}和原子分组(?...)。它们的作用是一旦匹配就不会回溯。将(a)改为(a)并不能消除嵌套问题但可以防止内层a回溯。更安全的改写是直接使用^a$占有型量词或^(?a)$原子分组。但请注意这改变了语义它们会进行贪婪匹配且不回溯在某些复杂场景下需谨慎使用。具体化匹配内容越是模糊的正则如.*越容易引发性能问题和安全风险。尽量用更精确的字符类如[A-Za-z0-9]替代通配符。4.2 利用Java正则引擎的超时机制JDK 9从JDK 9开始java.util.regex.Pattern类支持通过Matcher设置超时时间这是防御ReDos的一大利器。import java.util.regex.Pattern; import java.util.regex.Matcher; import java.time.Duration; public class SafeRegexWithTimeout { public static boolean safeMatch(String input, String regex) { // 编译正则时指定超时时间 Pattern pattern Pattern.compile(regex); Matcher matcher pattern.matcher(input); // 设置匹配操作的超时时间例如100毫秒 try { return matcher.find(); // 或 matches(), lookingAt() } catch (IllegalStateException e) { // 超时或其他运行时错误 // 注意JDK中超时是通过中断线程实现的可能会抛出IllegalStateException // 更准确的超时检测需要看异常信息或使用CompletableFuture包装 System.err.println(正则匹配可能超时或出错: e.getMessage()); return false; // 超时视为不匹配或根据业务逻辑处理 } } // 更现代的做法JDK 9使用Pattern.compile的重载方法 public static boolean safeMatchWithTimeout(String input, String regex, long timeoutMillis) { try { Pattern pattern Pattern.compile(regex, Pattern.TIMEOUT_MILLIS, timeoutMillis); return pattern.matcher(input).matches(); } catch (IllegalArgumentException e) { // 正则表达式语法错误 throw e; } // 注意当前JDK实现中超时是通过Thread.interrupt()触发的 // 如果匹配线程被中断可能会抛出IllegalStateException。 // 最佳实践是将匹配操作放在一个可中断的单独线程中。 } }重要提示JDK的超时机制并非绝对可靠它依赖于线程中断。如果正则引擎在某个不可中断的阻塞操作中超时可能失效。因此它应作为一道重要的补充防线而非唯一依赖。4.3 输入验证与长度限制在正则匹配之前进行前置的、轻量级的校验可以过滤掉绝大多数恶意输入。长度限制对于像用户名、邮箱、电话号码这类输入其长度有合理的现实上限。在调用String.matches()之前先判断input.length() 255举例如果超过则直接返回失败。这能瞬间阻断利用超长字符串发起的ReDos攻击。白名单字符过滤如果业务允许在正则匹配前先检查字符串是否只包含预期的字符集。例如如果只允许字母数字可以用一个简单的循环或String.matches(“[A-Za-z0-9]*”)先过滤一遍。这个简单正则没有复杂结构性能消耗极低。分层验证将复杂的单次正则匹配拆解为多个简单的步骤。例如验证一个复杂格式的字符串可以先验证长度再验证首尾字符再用简单正则验证部分结构最后才用复杂正则做完整匹配。这样恶意输入很可能在前几步就被拦截。4.4 使用第三方安全正则库对于安全性要求极高的应用可以考虑使用设计上就免疫ReDos的正则引擎库。Google RE2/J这是Google RE2引擎的Java移植版。RE2引擎在设计上就放弃了回溯功能保证了匹配时间与输入字符串长度呈线性关系从根本上杜绝了ReDos。代价是它不支持一些需要回溯的高级特性如反向引用\1。如果你的正则表达式不需要这些特性RE2/J是绝佳的选择。!-- Maven 依赖 -- dependency groupIdcom.google.re2j/groupId artifactIdre2j/artifactId version1.7/version /dependencyimport com.google.re2j.Pattern; // 用法与 java.util.regex.Pattern 几乎相同 Pattern safePattern Pattern.compile(^(a)$); boolean match safePattern.matcher(aaaaaaaaaX).find(); // 这将快速返回false其他选择社区还有一些其他安全导向的正则库但在Java生态中RE2/J的成熟度和兼容性相对较好。4.5 架构层面的隔离与降级在系统架构上也可以为可能遭受ReDos的端点增加保护。限流与熔断在API网关或应用层对特定接口如登录、搜索实施严格的QPS限流和并发控制。当某个IP或用户短时间内发送大量导致慢响应的请求时迅速熔断。隔离执行将耗时的正则匹配操作放到单独的、有资源限制的线程池中执行防止一个慢请求拖垮整个应用服务线程。监控与告警监控应用服务器的CPU使用率、线程阻塞时间、以及特定接口的P99/P999响应时间。一旦发现异常模式如某个包含正则校验的接口响应时间飙升立即触发告警。5. 代码审计与常见漏洞模式识别在日常代码审查或安全审计中如何快速识别潜在的ReDos漏洞点以下是一些高危模式和需要重点检查的代码位置。5.1 高危正则模式速查表漏洞模式示例风险说明安全改写建议嵌套量词(a),(.*)*,(a?)*指数级回溯风险极高简化结构(a)-a避免不必要的嵌套重叠分支(aaa),(aab)贪婪量词后接通配符.*a.*第一个.*会贪婪匹配到末尾然后回溯寻找a尽可能具体化或使用惰性量词.*?a.*需评估复杂的回溯引用(\w)\1虽然有用但结合不当的量词也可能导致性能问题确保被引用的组其匹配内容是确定性的避免模糊匹配5.2 需要重点审计的代码场景用户输入验证这是重灾区。所有String.matches(),Pattern.compile().matcher(input).matches()的地方尤其是验证用户名、密码、邮箱、URL、搜索关键词的代码。日志解析与提取从日志文件中用正则提取信息比如用jmeter正则提取器那样的功能。如果日志格式可能被污染或日志行非常长风险很高。模板渲染与文本替换类似于“根据要求替换HTML文档”中的操作如果替换规则使用了复杂正则且替换内容来自用户需警惕。数据清洗与格式化在处理来自外部系统或用户上传的文本数据时用于清洗、归一化的正则表达式。审计技巧在IDE中全局搜索Pattern.compile、String.matches、String.replaceAll、String.split其参数也是正则等关键字。逐一审查其使用的正则表达式特别是那些包含、*、{m,n}量词和|分支的组合。6. 性能测试与压模拟实战用JMeter验证接口韧性理论说再多不如一次压测来得直观。我们可以使用JMeter来模拟攻击验证我们的修复是否有效。假设我们有一个用户注册接口/api/register其中对用户名使用了有漏洞的正则^(a)$进行校验。6.1 构造JMeter测试计划创建线程组设置100个线程模拟并发用户循环次数设为“永远”并在调度器中设置持续时间如60秒。创建HTTP请求采样器协议http服务器名称localhost (你的测试服务器地址)端口8080路径/api/register方法POST添加Body Data (JSON){username: “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX”, “password”: “test123”}这里的用户名就是我们的攻击载荷30个a加一个X。添加HTTP信息头管理器设置Content-Type: application/json。添加监听器添加“查看结果树”和“聚合报告”。6.2 执行测试与观察攻击前使用危险正则启动压测。你会很快在聚合报告中看到吞吐量急剧下降可能接近0。平均响应时间和错误率飙升。在服务器监控中对应应用实例的CPU使用率会打到100%并且可能因为线程池耗尽导致其他健康接口也无法访问。攻击后修复为正则^a$或增加超时/长度限制再次执行同样的压测。吞吐量保持正常水平。平均响应时间稳定在毫秒级。服务器CPU使用率正常。注册接口会快速返回“用户名格式错误”之类的业务响应。这个简单的压测能清晰地展示一个不起眼的正则表达式漏洞在并发攻击下对服务可用性的毁灭性影响以及修复后的显著效果。6.3 将安全正则检查纳入CI/CD流程为了防患于未然可以将正则表达式安全检查作为代码提交或持续集成的一部分。使用静态代码分析工具如SonarQube、Find Security Bugs等它们通常内置了检测危险正则模式的规则。编写自定义的单元测试针对项目中所有使用的正则表达式编写专门的测试用例输入一个精心构造的“攻击字符串”如30个字符加一个破坏字符并断言匹配操作必须在极短时间如100毫秒内完成。如果测试超时则构建失败。Test(timeout 100) // 设置超时时间为100毫秒 public void testUsernameRegexAgainstReDos() { String dangerousInput “a”.repeat(30) “X”; // 如果这里使用了有漏洞的正则测试将超时失败 assertFalse(dangerousInput.matches(USERNAME_REGEX)); }7. 深入排查当服务疑似遭受ReDos攻击时如果线上服务突然出现CPU飙高、接口超时怀疑可能遭受了ReDos攻击可以按照以下步骤进行排查。7.1 即时诊断步骤定位热点线程使用top -Hp [pid]找到消耗CPU最高的Java线程ID。将线程ID转换为16进制例如printf “%x\n” 12345。使用jstack [pid] thread_dump.txt获取线程堆栈然后搜索上一步得到的16进制线程ID。你极有可能发现该线程正在java.util.regex.Pattern$...的match或study方法中这是正则引擎正在疯狂回溯的典型特征。分析请求日志检查在CPU开始飙高的时间点附近是否有大量请求涌向某个特定接口。查看这些请求的参数特别是文本类参数如username, query, content等是否包含大量重复字符或特殊模式。使用性能剖析工具使用Java Flight Recorder或Async-Profiler对运行中的Java进程进行采样分析。它们能生成火焰图直观地显示CPU时间都消耗在了哪些方法上。如果发现java.util.regex相关方法占据了绝大部分CPU时间那么ReDos的嫌疑就非常大了。7.2 临时缓解与长期修复临时缓解快速扩容与重启如果条件允许迅速增加服务实例并将疑似被攻击的实例下线重启以释放被占用的资源。WAF/网关层拦截在Web应用防火墙或API网关上紧急添加规则拦截包含超长重复字符模式如a{50,}的请求。应用层限流降级立即对该疑似被攻击的接口实施严格的限流甚至暂时降级返回静态错误页面。长期修复根据前面章节的防御策略定位并修复有漏洞的正则表达式。在全网代码中审计类似模式。考虑引入RE2/J等安全引擎对高风险场景进行替换。为所有正则匹配操作添加合理的超时控制。正则表达式是Java开发者手中强大的工具但正如所有强大的工具一样它需要被谨慎和明智地使用。理解ReDos不仅仅是为了通过一次Java面试更是为了构建出性能更稳健、更安全的应用程序。记住一个原则对待用户输入的正则表达式要像对待SQL语句一样永远保持警惕避免将控制权完全交给一个可能包含恶意负载的字符串。通过编写确定性正则、实施输入验证、设置超时机制和架构防护我们可以有效地将ReDos的风险降到最低。
