如何通过代码审计挖掘REDos漏洞

写这篇文章的目的一是由于目前网上关于java代码审计的资料实在是太少了，本人作为一个java代码审计的新手，深知学习java代码审计的难受之处，所以将自己学习过程中挖掘的一些漏洞写成博客发出来希望可以给后人一些帮助，同时也可以记录下自己的成长过程。目的二是由于这次挖掘的漏洞REDOS，个人觉得这个漏洞还是很有意思的，很早就知道这个漏洞了但是从来没有挖到过，终于在一个月前挖到了，很开心，记录一下。

先介绍下REDOS这个漏洞吧，可能很多人并不是很熟悉这个漏洞，一是由于这种漏洞造成的影响是拒绝服务，影响似乎不是很严重；二是这种漏洞一般需要通过白盒测试才能发现，通常的黑盒测试很难发现这种漏洞。

OWASP的对它的描述是：正则表达式拒绝服务（Regular expression Denial of Service-ReDoS)是一种拒绝服务攻击（Denial of Service ），它利用了大多数正则表达式实现可能会导致极端情况的原因，这些极端情况导致它们工作得非常缓慢（与输入大小呈指数关系），然后攻击者可以使用正则表达式导致程序进入这些极端情况，然后挂起很长时间。

说白了就是，应用程序中经常会有使用正则表达式去匹配字符串的情况，（1）如果开发人员对正则表达式的原理并不是很熟悉写出了类似“^(a+)+$”这样的正则，（2）由于业务需求，正则是动态构造的，且受用户控制。这两种情况，程序都可能受到REDOS攻击。大家可能第一眼看到“^(a+)+$”不会觉得这个正则有什么问题，这里也就是为什么说要懂原理才行。因为这里其实涉及到了编译原理的知识，我尽量讲清楚：

正则表达式引擎分成两类，一类称为DFA(确定性有限状态自动机)，另一类称为NFA(非确定性有限状态自动机)。两类引擎要顺利工作，都必须有一个正则式和一个文本串，一个捏在手里，一个吃下去。DFA捏着文本串去比较正则式，看到一个子正则式，就把可能的匹配串全标注出来，然后再看正则式的下一个部分，根据新的匹配结果更新标注。而NFA是捏着正则式去比文本，吃掉一个字符，就把它跟正则式比较，然后接着往下干。一旦不匹配，就把刚吃的这个字符吐出来，一个一个吐，直到回到上一次匹配的地方。也就是说对于同一个字符串中的每一个字符，DFA都只会去匹配一次，比较快，但特性较少，而NFA则会去匹配多次，速度相比会慢很多但是特性多啊，所以用NFA作为正则表达式引擎的会多些。现在我们再来看^(a+)+$,大家应该能看出些问题了，当我们用它去匹配“aaaax”这个字符串时，他需要尝试2^4=16次才会失败，当我们这个字符串再长一点时，需要尝试的次数会成指数增长，aaaaaaaaaaX就要经历2^10=1024次尝试。

如下图：

可以看到java、php、python都是用的NFA（JS中好像也是），也就是说这些语言中用了正则的api都是可能存在问题的哦。比如java中比较常见的split,replaceAll等，这些方法中既可以接受字符串也可以接受正则表达式的。

说了这么多，准备进入正题吧，为什么一个月前就发现漏洞了，现在才写博客呢，本来是想等作者修复漏洞后再写博客的，但是因为github上的作者到现在都没有回复我，似乎并不准备修复，而我也懒得等了，直接将漏洞披露出来吧，毕竟漏洞影响不大，并且漏洞和程序上下文的联系也不大，复现的时候只需要将缺陷代码单独拿出来在本地复现即可。

这整个java文件是将文件转化为pdf格式的一个工具类，在转化文件格式的同时还需要将文件名的后缀也修改下。如上两个方法就是用来修改文件名后缀的。getOutputFilePath(String inputFilePath)用于将文件名的后缀修改为.pdf，而文件名后缀是通过getPostfix(String inputFilePath)这一方法截断文件名中最后一个.后面的内容来获取的。简单介绍下String.replaceAll(a,b)的意思就是将String中的字符串a全部替换成字符串b。比如说”aabbcc”.replaceAll(“a”,”b”),输出结果为“bbbbcc”,上面也说了a可以是正则表达式当”aabbcc”.replaceAll(“(a)+”,”b”),输出结果为“fbbcc”。再回过头看代码，如果我们已知参数inputFilePath是可控的，怎样设置这个值才能触发REDOS攻击呢？

首先参数inputFilePath的后缀必须控制成一个真正表达式的样，我们可以先设置为.(a+)+,而.(a+)+作为正则表达式去匹配inputFilePath时，inputFilePath的前半部分必须符合这个正则才不至于匹配没开始就结束了，所以inputFilePath的前半部分也应该类似.aaaa这样，再和后缀拼凑起来就是.aaa.(a+)+

Ok,本地搭建环境测试一下：