从一次 CPU 打满到 ReDos 攻击和防范
作者:京东物流 刘海茂
近期碰到一起值班报警事件,web 应用服务器 CPU 消耗打到 99%,排查后发现是因为 ReDoS 导致了服务器发生了资源被耗尽、访问系统缓慢的问题,通过排查过程从而分享下 ReDos 攻击的原理、常见场景以及防范和解决方案,如果有错误欢迎指正。
背景
值班的时候突然报警,web 应用服务器 CPU 消耗打到 99%,同时现场反馈系统访问缓慢
登录泰山平台,查看 ump 监控发现系统消耗 CPU 消耗突然被打满
通过 java 自带的 dump 工具,下载 jstock 文件,发现有大量相同任务线程在运行,具体的堆栈信息如下
仔细查看这些线程的执行代码,发现都调用了 UrlUtil.extractDomain 这个方法
根据堆栈信息查看业务代码,发现是 joybuy 登录拦截器用正则表达式匹配访问 url 解析主域的方法出现了阻塞,至此,可以判断是因为 ReDoS 导致了服务器发生了资源被耗尽、访问系统缓慢的问题,那么,什么是 ReDoS 呢?
ReDos 简介
ReDoS 攻击(正则表达式拒绝服务攻击(Regular Expression Denial of Service)),攻击者可构造特殊的字符串,导致正则表达式运行会消耗大量的内存和 cpu 导致服务器资源被耗尽。无法继续响应,那为何不确定的正则表达式会导致 redos 攻击呢?这得从正则表达式的实现原理说起
原理
目前实现正则表达式引擎的方式有两种
DFA 自动机(Deterministic Finite Automaton,确定有限状态自动机)
NFA 自动机(Nondeterministic Finite Automaton,非确定有限状态自动机)
DFA 自动机的构造代价远大于 NFA 自动机,但 DFA 自动机的执行效率高于 NFA 自动机
假设一个字符串的长度为 n,如果采用 DFA 自动机作为正则表达式引擎,则匹配的时间复杂度为 O(n)
如果采用 NFA 自动机作为正则表达式引擎,NFA 自动机在匹配过程中存在大量的分支和回溯,假设 NFA 的状态数为 s,
则匹配的时间复杂度为 O(ns)
NFA 自动机的优势是支持更多高级功能,但都是基于_子表达式独立进行匹配_
因此在编程语言里,使用的正则表达式库都是基于 NFA 自动机实现的
NFA 的特性:
1.一个有限的状态集合 S
2.一个输入符号集合 sigma,空字符 epsilon 不属于 Sigma
3.状态迁移函数 F,对于特定的输入字符和状态,输出对应的变更状态集合
4.s0 为初始状态
5.S 子集为结束状态集
说明
定义一个正则表达式^(a+)+$来对字符串 aaaaX 匹配。使用 NFA 的正则引擎,必须经历 2^4=16 次尝试失败后才能否定这个匹配。
同理字符串为 aaaaaaaaaaX 就要经历 2^10=1024 次尝试。如果我们继续增加 a 的个数为 20 个、30 个或者更多,那么这里的匹配会变成指数增长
常见 ReDoS 场景
以 java 为例,有以下几种常见的 ReDoS 场景:
1、使用 javax.validation.constraints.Pattern 验证入参是否合理的场景
2、使用 String.matches 进行业务数据验证的场景
3、使用 String.replaceAll 做参数替换的场景
4、配置文件匹配参数的场景
ReDoS 检测
1、RegexStaticAnalysis 工具
测试方式如下:
使用 maven package 打包后执行本地运行,输入需要测试的正则表达式
2、在线测试地址:https://regex101.com/
测试方式:
直接在输入框输入正则表达式和需要测试的字符串,既可以看到对饮匹配的步数和结果
在 dubugger 模式下可以查看匹配的详细过程和步数
防范手段
防范手段只是为了降低风险而不能百分百消除 ReDoS 这种威胁。当然为了避免这种威胁的最好手段是尽量减少正则在业务中的使用场景或者多做测试, 增加服务器的性能监控等
降低正则表达式的复杂度, 尽量少用分组
严格限制用户输入的字符串长度
使用单元测试、fuzzing 测试保证安全
使用静态代码分析工具
增加性能监控,如 ump、pfinder 等
解决方法
了解了 ReDoS 的原理和防范,针对本次 CPU 的报警代码进行了优化,采用判断请求路径和分割字符串的方式获取访问的域,避免使用正则表达式导致的 ReDoS 问题
实际修复代码
版权声明: 本文为 InfoQ 作者【京东科技开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/a20a8890c64820ebca80d2697】。文章转载请联系作者。
评论