做为一枚纯正的甲方安全人员，代码审计是必备技能点。在实际工作中，代码审计无论是在安全测试中所占的投入比重，亦或是在发现产品/项目安全漏洞中的比例，都比黑盒渗透要大的多。因此，博主特意开辟了该代码审计系列博文，结合了博主在某厂实际工作中的工作经历和厂内大牛前辈们的经验，稍加提炼而成。
在正式开始专项之前，先简单介绍下“代码审计渗透测试”这个自创的新词：
一般来讲，Web安全测试主要分为黑盒测试和白盒测试:
黑盒测试是指测试人员不清楚Web具体的架构和实现，通过模拟一个或多个攻击角色进行渗透测试，发现潜在的安全漏洞和风险，它不会泄露系统源码。
白盒测试则需要开发人员提供相关的设计文档、源码、使用手册、业务逻辑等信息，对源代码直接进行安全分析，来寻找安全漏洞和可能存在的风险，它主要用于公司内部进行深度安全测试。代码审计是白盒测试常用的一种方法。
代码审计渗透测试则是将黑盒渗透测试的思路用于代码审计的一种方法，博主将从漏洞介绍、漏洞原理、测试思路和测试方法四个方面来阐述TOP N的Web安全漏洞的代码审计渗透测试。

漏洞介绍

SQL注入漏洞是Web常见的漏洞，通过此漏洞可能用来拖库、获取Web管理员账号和密码、权限提升等攻击，是Web安全中最严重的漏洞之一。

注意：本章节仅讨论关系型数据库，不适用非关系型数据库。

漏洞原理

SQL注入(SQL Injection)，就是通过把SQL命令插入到Web表单提交或页面请求的字符串中，最终达到欺骗数据库服务器执行恶意的SQL命令,从而达到攻击的目的。
用户输入的内容，传递到服务端后没有做有效的过滤，后端拿到用户输入的不安全的内容后当做SQL命令直接执行，从而改变了原来的业务的SQL运行流程或者在执行了原有的SQL语句后，附加执行了用户的恶意SQL语句，导致数据库信息泄露或者权限提升。

举个栗子：
username:
password:
前台需要输入用户名和密码。
后台的处理代码如下：

1 2 3

username = getRequestName("UserName"); password = getRequestPassword("UserPasswd"); sql = "SELECT * FROM USER WHERE name = '" + username +"' AND passwd = '" + password + "'";

这里后台拿到前端传参后没有做任何处理，直接拼接了SQL语句，这就很容易被SQL注入了：
username: admin’ or ‘1’ = ‘1
password: anything
这时候，后台构造的语句即为：

1	sql = "SELECT * FROM USER WHERE name = 'admin' or '1' = '1' AND passwd = 'anything';

来分析这个SQL语句，你会发现，不管密码输入什么（anything），这条语句总会返回true，因为where xx or ‘1’ = ‘1’ 是恒成立的。因此用户不需要知道用户名和密码就能够成功登录到系统。

从上面例子可以看出，用户可以构造出改变原本程序的运行逻辑的恶意代码，从而导致SQL注入。

更多SQL相关的知识详见：SQL_Injection

测试思路

渗透测试前，先要与开发人员进行沟通确认，找到存在用户输入并且需要操作数据库的地方，再去看是否进行了防SQL注入的安全机制，该安全机制是否能被绕过等。常见的比如使用预编译:

PHP:可以使用mysqli、PDO实现预编译
Java:可以使用preparestatement预编译

在SQL注入的测试中，仅仅通过黑盒渗透是远远不够的，原因如下:

• AppScan/AWVS无法获取到所有的业务报文，Burp可以获取较多的报文，但是注入用例太少，不能进行全面的覆盖，因此导致很多工具都没法进行全面的SQL注入渗透测试
• 渗透测试工具没法进行一些需要特定条件才能注入成功的操作，或者是正常场景不会出现的情况，容易产生遗漏

因此针对SQL注入，强烈推荐使用本文源码分析为主，黑盒测试为辅。源码分析遵从以下规则：

• 未使用预编译的，必须换为预编译，如果存在不能预编的场景，需要单独拿出来进行安全分析；
• 使用预编译的，必须使用占位符，不能针对sql拼接。

黑盒测试

在测试前，通过与开交流或者源码源码分析，了解Web中使用的所有数据库名称及版本号，包括关系型数据库（MySQL、Oracle、SQLite等）,然后针对性测试，减少测试工作量。黑盒测试思路如下：

1）Web漏洞扫描
利用Web漏洞扫描工具如AppScan、AWVS、Burp自动扫描，可以发现部分注入SQL注入漏洞，针对发现的漏洞“点”，在源码分析漏洞产生的原因，然后全面排查类似问题。

2）手工SQL注入
在Web界面中找到可能存在数据库操作的点，例如用户用户、数据查询、添加用户等场景，然后尝试手工测试，来发现比较隐蔽，以及工具难以覆盖的SQL注入漏洞。

源码分析

通过分析源码，识别可能被绕过的SQL注入场景，例如绕过正则、关键字过滤、编码等，常见的SQL注入根因如下：

• 直接拼接SQL语句，导致存在SQL注入
• 不正确使用预编译导致存在SQL注入
• 通过拼接，有过滤但过滤不全能被绕过导致SQL注入
• 第三方框架导致SQL注入（如Hibernate、iBatis……）
• 其它原因导致存在的SQL注入

测试方法

Web漏洞扫描在测试工具中有详细介绍，因此本章节测试方法重点介绍手工SQL注入和Web源码分析SQL注入。

非预编译导致的SQL注入

大部分SQL注入漏洞的根因都是因为没有使用预编译，使用SQL语句拼接，导致用户构造的恶意语句改变了原有的SQL流程。测试方法如下：
1）通过手动搜索关键字分析SQL拼接场景是否存在漏洞，关键字如下：
PHP关键字：query 、mysql_query 、mysql_fetch_array ……
Java关键字：Statement 、.execute 、.executeQuery、jdbcTemplate、queryForInt、queryForObject、queryForMap、getConnection
2）分析SQL执行的场景是否使用了预编译，以java为例，可以通过搜索关键字queryForInt搜索到的代码假设如下：

1
2
3
4
5
6
7
8
9
10

private static String STR_QUERY_FILE = "SELECT COUNT(1) FROM TBL_XXX WHERE XXX_FILENAME = '%s'";
public boolen isXXXFileUsed(String strFileName){
    String strSql = String.format(STR_QUERY_FILE, strFileName);
    if(Constant.NUMBER_ZERO < getSimpleJdbcTemplate().queryForInt(strSql)){
    ......
    }
    ......
    return flase;
}

STR_QUERY_FILE为SQL语句查询字符串，strFileName为客户端传参，也就是该参数由用户直接输入，即用户可控，这里并没有进行过滤，也没有进行预编译，直接使用format进行字符串拼接后执行SQL，因此此处是存在SQL注入漏洞的。
漏洞利用Exploit如下：

1

a.dat; delete from user;

错误的预编译导致的SQL注入

有时候开发人员虽然使用了预编译，但是错误的预编译仍然是存在SQL漏洞的，因此代码审计时需要分析PreparedStatement时是否使用占用符，测试方法如下：
1）通过搜索关键字，先找到使用预编译的场景，关键字如下：
PHP关键字：prepare 、execute
Java关键字：preparedStatement
2）分析代码是否存在漏洞，预编译之前的参数绑定应该使用占位符，不应该直接使用拼接。例如：

1
2
3
4
5
6
7
8

strSql = "SELECT uu_name from table_appmanage ";
if(uu_key != null){
    strSql.append("where key = '" + uu_k + "'");
}
sql = strSql.toString();
ps = conn.preparedStatement(sql);
re = ps.executeQuery();
.....

这里虽然使用了preparedStatement预编译，但是在预编译之前，append拼接参数时已经被污染，所以这里也是无法防御SQL注入的。正确的方法应该如下：

1
2
3
4

strSql = "SELECT uu_name from table_appmanage where key = ? ");
PreparedStatement ps = conn.preparedStatement(sreSql);
ps.setString(1, uu_key);
re = ps.executeQuery();

过滤不完整导致SQL注入

在有些场景没办法使用预编译。比如建表的SQL语句没法使用参数绑定+预编译来放回SQL注入，这个时候就需要进行SQL动态拼接，而防止SQL注入就需要进行特殊字符的过滤，一般大家都喜欢使用黑名单，而黑名单却是最容易绕过，无法达到防护的目的。这种情况的测试方法如下：
1）在源码中搜索如下关键字，找到相关的代码：
PHP关键字：query 、mysql_query、mysql_fetch_array ······
Java关键字：statement、execute、jdbcTemplate、queryForInt、queryForObject、queryForMap、executeQuery、getConnection ······
2）分析测试是否存在绕过的风险，例如（PHP）：

1
2
3
4
5
6
7
8
9

$sid = strtolower($_REQUEST[id]);
    $key1 = array("=", "order", "or", "xor", ">", "<", "null");
    $id = str_replace($key1,"", $sid);
    $conn = mysql_connect($servername, $dbusername, $dbpassword) or die("connect db failed");
    mysql_select_db($dbname, $conn);
    mysql_query('set names utf8');
    $sql = "select * from article where articleid = $id";
    $result = mysql_query($sql, $conn);
    $row = mysql_fetch_array($result);

这里使用的是MYSQL数据库，没有使用参数绑定加预编译的形式，id参数来源于客户端请求，开发人员意识到存在SQL注入安全风险，进行SQL执行前使用了str_replace进行了字符过滤，将$key1中的字符替换为空，实际上这样过滤远远不够，使用union就可以轻松绕过，漏洞利用可以参考：

1

/index.php?id=-1 union select 1,2,3

Hibernate导致的SQL注入(仅存在于java)

Hibernate是一个开源的java框架，它对JDBC进行了非常轻量级的对象封装，它可以生成SQL语句，自动执行，使得java程序员可以自由的使用OOP思想来操纵数据库，因此深受欢迎。
Hibernate本身支持预编译，但是如果使用动态拼接，则也会存在SQL注入风险，测试方法如下：
1）判断web中是否使用了Hibernate，搜索如下关键字：
Hibernate关键字：org.hibernate
2）分析是否为SQL拼接，搜索一下关键字分析相关代码是否存在拼接：
关键字：.createQuery
例如：

1
2
3

String username = request.getParameter("username");
String str = "from user_table where name = " + username;
Query q = session.createQuery(str);

代码中通过Hibernate来查询数据库，username为外部输入参数，然后与sql动态拼接，因此存在SQL注入漏洞。

安全的使用方法应该是使用占位符进行参数绑定，再使用预编译：

1
2
3
4

String username = request.getParameter("username");
String str = "from user_table where name = ?";
Query q = session.createQuery(str);
q.setString(0, username);

iBatis/myBatis导致的SQL注入(仅存在于java)

iBatis(后被谷歌托管，改名为myBatis)是用于使用方便的数据访问工具，也主要作为数据持久层，与ORM(Hibernate)类似。i/myBatis中#是占位符，$是字符串拼接，所以尽量使用#可以避免SQL注入，而$则会存在风险，测试方法如下：
1）判断web中是否使用了iBatis/myBatis,在源码中搜索以下关键字，如果存在说明项目中使用了iBatis/myBatis，关键字如下：
iBatis关键字：import com.ibatis
myBatis关键字：import org.mybatis
2）判断SQL调用时，是否使用了$拼接。例如：

1
2
3

<select id="testSQL" parameterClass="com.it.users" resultClass="users">
SELECT * FROM users WHERE username = '$username$'
</select>

这里使用的就是$username$，进行了SQL拼接，username被用户恶意输入则造成了SQL漏洞。
正确的使用应该是：

1
2
3

<select id="testSQL" parameterClass="com.it.users" resultClass="users">
SELECT * FROM users WHERE username = #username#
</select>

其他原因导致的SQL注入

PHP的SQL注入更加灵活复杂，也存在上面类似的ORM框架，同理也就可能存在SQL注入风险，但是往往结果框架的包装后，就很难轻易的识别出这些安全风险，给白盒渗透测试带来困难。除了上述因素外，还有其他场景和因素导致SQL注入：
1）字符编码导致SQL宽字节注入
2）不正确的使用安全函数导致的SQL注入，尤其是PHP弱语言最容易发生
3）代码逻辑导致的SQL注入
尤其是代码逻辑，这个需要深入熟悉业务，也需要有较强的逻辑思维能力。

PS：
1)产品安全测试过程中测试量大，参数多，因此最高速有效的测试方法就是基于正常报文添加单双引号，然后查看数据库日志。当然如果你非常熟悉手工注入也可以直接构造出SQL来证明是存在漏洞的。
2)在实际排查的过程中，使用关键字搜索，大多数会得到很多结果，如果一个一个的去分析调用，参数是否可控，工作量相当大，并且很容易产生漏洞。这时，就需要开发人员先将能使用预编译的地方使用参数绑定+预编译，然后再去详细分析不能使用预编译的地方进行定点分析，提高开发和测试效率。

背景

10月7日下午4点58分，十堰到武汉动车。10月8日凌晨6点多武汉到广州的票（虽然后来换票了）。
10月7日、10月8日，十堰到武汉的车都无票。

关于时间节点，描述精确的要么是我看过表，要么是电话记录，要么是滴滴订单。不确定的，描述中会使用x分左右。

事情是这样的

10月7日中午参加完婚礼，时间1点50，一行四个人闲来无事，买了4张票去看羞羞的铁拳，2点10分到3点50多。
看完出来上厕所等电梯拿行李等，到马路边叫了滴滴等，此时4点15分，动车开车时间是4点58分。
此时找身份证准备待会儿取票用的时候才发现钱包不见了。赶紧翻包翻箱子，没有找到。

4点17分左右，滴滴来了，让另外俩小伙伴先走，我和妹子再找找。他们走后，我直接跑到结婚酒店的前台问，告知婚礼的负责在4楼前台，迈着刚爬了青城山和武当山两座大山的酸腿飞奔上四楼，告知没有人捡到，让我自己去5楼大厅看看，此时已经明白基本无望了，还是飞奔而去，果然都收拾干净了，再飞奔下一楼。
看时间4点21了。来不及了，错过了这趟车，今天就没有车回武汉，明天也就回不了深圳，明天也没有车去武汉的。。决定先去火车站看能不能搞到临时证明，先去武汉再说。

4点23分，滴滴接单。

4点24分，司机打来电话。

4点27分，上车。

4点45分，快到车站的时候，堵车，和妹子商量，我先去跑过去搞证明，取票。

4点46分，拿了她的身份证下车狂奔。此时离开车还有12分，一切顺利就还来得及，只能这么安慰自己。

你以为老天的考验就这样了？太单纯了。我当时也是。太单纯了。

4点59分左右，到达人工售票窗口，问清了哪里办临时证件，跑过去，有人在办，窃喜，再一问，告知需要一张照片。WTF，这什么卵规定，我TM现在去哪里弄，工作人员一指，马路对面，我一看时间，4点50了，马路对面？你逗我？目测一里多路，还得找照相馆，还得照，还得洗出来，这怎么可能来得及？感觉世界已经崩塌，自己是走不了了，赶紧去自动取票机帮妹子取了票，等她来了让她先走，能走一个是一个。

4点51分，妹子一个人拖着箱子，背着一个包，提着包，走过来了，看我在这里等，估计以为都搞好了，结果我拿出一张票给她，你先走，我是走不了了。她愣了一下，也急了，最后问清楚了，说再去说了看看，我说我说过了，不让，必须要照片。
最后，4点52分，又去了窗口，这次我们一起说，更显急迫，工作人员 终于答应了，内心狂喜。以为运气来了，结果发现自己还是太单纯。

4点53分，办好了临时证明，让妹子带着行李先进站了，因为订单号在她手机上，无证取票要订单号，于是我拿着她的手机狂奔去人工取票。三个窗口开着，直接去第一个，插队问，回答她这里办不了，去另一个。到另一个，正在办理，问了两遍不理我。我去第三个，办不了，只能第二个。又跑去第二个，再问，还是不回答，看着她不忙不急的办理，不经历的很难理解当时是一种是心情。

4点55分，还没办完，忍不住了，再次问能不能先帮我搞下，我58分车。“我搞了半天。总不能取消掉吧，你等着！”我当时竟然笑了。然后看着她又点了会儿，拿出4个身份证一个一个刷，一个一个出票，后面人都看着我，眼里满是同情。第一个买票的大爷，也有点不好意思，抬头看了看我，又看了看售票员，最后低头没说话。我笑着摇了摇头。

4点57分，到我了，本来已经绝望了，但是票还是得取，20秒取票走人，不忘说一句谢谢。

再晚一分钟，票过了58分就取不出来了。

这时候，其实我已经可以放弃了。因为按照常理已经停止检票，就算让你进去了，也只能看着车走了。

但是我还是疯狂的跑进去了，虽然内心真真正正的已经绝望。

安检，因为没有行李，所以很快

4点58到检票处，看到妹子在检票口叫我赶紧，愣了一下，边想着怎么还没停止检票，边飞奔过去。

检票进去后，看到了之前的俩小伙伴，很是惊讶，一问，他们都说，我运气好，动车起点站晚点的，第一次遇到。不然，我这肯定是赶不上了。

我这运气，到底是好，还是不好。一言难尽。

进去后，才发现本来已经酸疼的腿，这一路上竟然一点感觉都没有，直到在车上坐下来才瑟瑟发抖。。。

什么？损失？钱不多，就几十块人民币加几十块港币，记起来200不到。但是身份证，4张银行卡，1张社保卡。。。后续会有多麻烦。

教训：以后还是得放些钱在钱包，只有钱包有钱了，平常才会记得时时看看，才会重视。不然，这次没钱，连什么时候掉的都想不起来。。

所以啊，人生呢
不迈出第一步，你永远不知道下一步在哪里。
不走到最后一步，你永远不知道结局是什么。

同名博客发表于菊厂3ms

Regular expression Denial of Service (ReDoS)是一种利用程序实现时采用了不安全的正则表达式，从而构造特定输入引起DOS拒绝服务的一种攻击手段。

在正式讨论ReDos之前，先来介绍一下预备知识。

Regex与DFA、NFA

不想看原理可以直接跳过去看例子，部分人可秒懂

正则表达式，又称规则表达式，英文名为Regular Expression，在代码中常简写为regex、regexp或RE，是计算机科学的一个概念。

正则表通常被用来检索、替换那些符合某个模式(规则)的文本。

正则表达式是对字符串（包括普通字符（例如，a 到 z 之间的字母）和特殊字符（称为“元字符”））操作的一种逻辑公式，就是用事先定义好的一些特定字符、及这些特定字符的组合，组成一个“规则字符串”，这个“规则字符串”用来表达对字符串的一种过滤逻辑。

正则表达式是一种文本模式，模式描述在搜索文本时要匹配的一个或多个字符串。

DFA 引擎在线性时状态下执行，因为它们不要求回溯（并因此它们永远不测试相同的字符两次）。
DFA 引擎还可以确保匹配最长的可能的字符串。
但是，因为 DFA 引擎只包含有限的状态，所以它不能匹配具有反向引用的模式；并且因为它不构造显示扩展，所以它不可以捕获子表达式。

传统的 NFA 引擎运行所谓的“贪婪的”匹配回溯算法，以指定顺序测试正则表达式的所有可能的扩展并接受第一个匹配项。
因为传统的 NFA 构造正则表达式的特定扩展以获得成功的匹配，所以它可以捕获子表达式匹配和匹配的反向引用。
但是，因为传统的 NFA 回溯，所以它可以访问完全相同的状态多次（如果通过不同的路径到达该状态）。
因此，在最坏情况下，它的执行速度可能非常慢。因为传统的 NFA 接受它找到的第一个匹配，所以它还可能会导致其他（可能更长）匹配未被发现。

POSIX NFA 引擎与传统的 NFA 引擎类似。
不同的一点在于：在它们可以确保已找到了可能的最长的匹配之前，它们将继续回溯。
因此，POSIX NFA 引擎的速度慢于传统的 NFA 引擎；并且在使用 POSIX NFA 时，您恐怕不会愿意在更改回溯搜索的顺序的情况下来支持较短的匹配搜索，而非较长的匹配搜索。

• 使用DFA引擎的程序主要有：awk,egrep,flex,lex,MySQL,Procmail等；
• 使用传统型NFA引擎的程序主要有：GNU Emacs,Java,ergp,less,more,.NET语言,PCRE library,Perl,PHP,Python,Ruby,sed,vi；
• 使用POSIX NFA引擎的程序主要有：mawk,Mortice Kern Systems’ utilities,GNU Emacs(使用时可以明确指定)；
• 也有使用DFA/NFA混合的引擎：GNU awk,GNU grep/egrep,Tcl。

下面用实例来说明正则匹配时，NFA与DFA引擎的区别：

1
2

字符串： hello regextest
正则表达式：  \reg(axtest|extext|extest)

DFA：拿着字符串文本去匹配正则表达式。
hello没有正则匹配的，去掉，reg匹配上了，继续；exte和第二、三分支匹配，继续；st和第三分支匹配，至此，regextest匹配成功，结束。过程中字符串只遍历了一次。

NFA：拿着正则表达式去对比字符串文本。
r->淘汰hello，匹配到r，e->e，g->g，a->e失败，回溯到上一个匹配的g，匹配下一个正则，e->e，x->x，t->t，e->e，x->s失败，回溯到上一个匹配的e，匹配下一个正则，s->s，t->t，匹配成功，结束。过程中字符串遍历了多次。

DOS

DOS攻击这里引用段子嘎的介绍：
DoS（Denial of Service，拒绝服务）是一种网络攻击手段，通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的。
形象一点的比喻是，你开了一家小面馆，黑客派了几个广场的大爷大妈涌入你的店里坐着吹空调，也不消费就霸着场子，导致其他顾客根本无法进店消费。
想详细了解可自行去查资料。

下面开始介绍本文重点：ReDos

原理

本文主要介绍使用NFA引擎的程序语言，使用DFA引擎的程序不存在ReDos。因为NFA引擎的回溯机制，导致了当字符串文本与正则表达式不匹配时，所花费的时间要比匹配时长的多。
简单点说，确定匹配成功就不做了，但是要确定匹配失败，则需要与所有可能的路径进行对比匹配，都证明匹配不了，才能确定匹配失败。

此时，如果使用简单的非分组正则表达式来进行匹配，也不会引起问题，例如：

1

^\d+$

• 1）23x
  23,x　　2,3x 　　23x
  标粗部分为确认不匹配的部分，第一次遇到不匹配时回溯到上一个继续进行匹配，共3次

• 2）123x
  123,x　　12,3x　　1,23x　　123x
  标粗部分为确认不匹配的部分，第一次遇到不匹配时回溯到上一个继续进行匹配，共4次

此时呈线性增长。

但是，如果使用重复性分组正则表达式来进行匹配，则可能引起问题，例如：

1

^\(d+)+$

• 1）23x
  23,x　　2,3,x　　2,3x 　　23x
  标粗部分为确认不匹配的部分，迭代多次才能确认原字符串不匹配，总共需要2^2 = 4次

• 2）123x
  123,x　　12,3,x　　12,3x　　1,23,x　　1,2,3,x　　1,2,3x　　1,23x　　123x
  标粗部分为确认不匹配的部分，迭代多次才能确认原字符串不匹配，总共需要2^3 = 8次

此时呈指数增长。

验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# coding:utf-8
import time
import re
strs = (
    '1234567890x',
    '12345678901234567890x',
    '1234567890123456789012345x',
    '12345678901234567890123456x',
    '123456789012345678901234567x',
    '1234567890123456789012345678x',
    '12345678901234567890123456789x'
)
regex = '^(\d+)+$'
def fun(strs, regex):
    t1 = time.time()
    result = re.compile(regex).match(strs)
    t2 = time.time()
    print("%s : %s : %.2f" % (strs, str(result), (t2 - t1)))
for s in strs:
    fun(s, regex)

运行结果：

1
2
3
4
5
6
7
8
9
10

C:\Python\Python36\python.exe D:/python/get_hi3ms_user_files/redos/redos.py
1234567890x : None : 0.00
12345678901234567890x : None : 0.09
1234567890123456789012345x : None : 2.95
12345678901234567890123456x : None : 5.92
123456789012345678901234567x : None : 12.51
1234567890123456789012345678x : None : 24.68
12345678901234567890123456789x : None : 52.39
Process finished with exit code 0

可以看出每增加一位，其运行时间呈现指数增长。

再来查看运行时的CPU占用，测试机子为4核电脑，单进程跑，CPU25%，单核占满了。

同时运行4个程序就能跑满100%CPU，可造成拒绝服务。

影响

容易引起ReDos的正则表达式主要有两类：
1、 包含具有自我重复的重复性分组的正则，例如：

1
2
3
4
5

^(\d+)+$
^(\d*)*$
^(\d+)*$
^(\d+|\s+)*$
…

2、 包含替换的重复性分组，例如：

1
2
3

^(\d|\d|\d)+$
^(\d|\d?)+$
…

目前已经在使用的，甚至是一些官方提供的正则表达式，也可能存在缺陷：

1、 正则表达式库网站中，提供的专门用于验证电子邮件的正则

1

/^([a-zA-Z0-9])(([\-.]|[_]+)?([a-zA-Z0-9]+))*(@){1}[a-z0-9]+[.]{1}(([a-z]{2,3})|([a-z]{2,3}[.]{1}[a-z]{2,3}))$/

输入：aaaaaaaaaaaaaaaaaaaaaaaa!

2、 OWASP验证正则表达式库，这也是一个有缺陷的正则：

1

^(([a-z])+.)+[A-Z]([a-z])+$

输入：aaaaaaaaaaaaaaaaaaaaaaaa!

3、 常用的：
多个邮箱地址验证

1

^[a-zA-Z]+(([\'\,\.\-][a-zA-Z ])?[a-zA-Z]*)*\s+<(\w[-._\w]*\w@\w[-._\w]*\w\.\w{2,3})>$|^(\w[-._\w]*\w@\w[-._\w]*\w\.\w{2,3})$

输入: aaaaaaaaaaaaaaaaaaaaaaaa!

复数验证

1

^\d*[0-9](|.\d*[0-9]|)*$

输入: 1111111111111111111111111!

模式匹配

1

^([a-z0-9]+([\-a-z0-9]*[a-z0-9]+)?\.){0,}([a-z0-9]+([\-a-z0-9]*[a-z0-9]+)?){1,63}(\.[a-z0-9]{2,7})+$

输入: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!

另外，攻击者也可能通过输入来自己构造缺陷正则，从而发起攻击：
例如：

1
2
3
4

String userName = textBox1.Text;
String password = textBox2.Text;
Regex testPassword = new Regex(userName);
match match = testPassword.Match(password);

此时，攻击者输入：

1
2

Userame：^(( [az])+.)+ [AZ]([az])+$
Password：aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa！

则会引起ReDos.

风险因素

在web的每一层都包含有正则表达式，也就是每一层都会存在有缺陷的正则风险。
攻击者能够攻击Web浏览器（PC端或者移动端）、WAF、数据库或者是Web服务器。

检测

其实理想的方法是在代码编译时用一个正则去查找匹配存在缺陷的正则表达式，然而搜索了一下，没有找到这种有效的正则。目前比较好的检测手段主要分两种。

• 一是静态代码工具分析，通过抓取代码中的正则去匹配已知的存在缺陷的特征库，重点需要检测存在分组和重复的正则，这种方法的准确率主要依赖于特征库的质量。
• 二是通过模糊测试去程序中进行检测。在使用了正则的地方不断使用多种字符串去进行输入匹配，记录下引擎在判断是否匹配时花费的时间，时间过长则很有可能存在不安全的正则。这种方法依赖于构造的字符串是否够全面。

防御

目前主要的防御手段主要还是在程序中避免出现不安全的正则：

• 1、 在编写正则的时候，尽量不要使用过于复杂的正则，越复杂越容易有缺陷，且越不容易进行全面的测试；
• 2、 编写正则的时候，尽量减少分组的使用量，使用的越多出现缺陷的可能性越大
• 3、 避免动态构造正则（即new Regex(…)），如果需要构造，也保证不要使用用户的输入来进行动态构造。
• 4、 严格限制用户输入的长度限制。

服务端可以进行性能监控，暂时还没法进行有效的防御。

参考链接：
https://msdn.microsoft.com/zh-cn/magazine/ff646973.aspx
https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS
https://baike.baidu.com/item/%E6%AD%A3%E5%88%99%E8%A1%A8%E8%BE%BE%E5%BC%8F/1700215?fr=aladdin
http://www.freebuf.com/articles/network/124422.html

人啊，总很珍惜回忆，也不是活在过去，
只是觉得人真正的财富，不是存在的那一串数字，
而是你正享受的现在和你脑海里存在的过去。
未来是期待，却不一定是你能拥有的。

来到新的环境已经两月有余，短短的两个月似乎过去了好久，
以至于刚刚结束的研究生生涯就已经在记忆中渐渐模糊了。
蓦然回首，惊觉记忆不如前啊。
也可能是累的。
虽说过去已是过去，但我还是喜欢以文字的形式记录下来。
于是，就有了华科印象。

细说印象之前，先来介绍一下华科。
官方名曰华中科技大学，老一辈称之为华工，我这一代人口中的华科，未来可能盛行的华中大，
以及很多人自嘲的关山口男子职业技术学院。
名字就像他的历史一样复杂。
然而他最神奇的不是这个，而是省内名气与武大比肩，出了省却只见武大，未闻华科。
记得一次与菊厂高管聊天
“哪里毕业的？”
“华科！”
“哦”
良久，追问一句
“在哪个城市？”
心里暗叹，保密工作做的这么好的，华科也算是在如今这浮躁社会的一股清流了。

毛爷爷像和他背后的南一楼

说到华科，就不得不说南大门的毛爷爷像。
这个如今被新生各种戏说解读的历史性雕塑，在早四十年那可是神圣不可侵犯的存在。
现在早已过了那个疯狂的年代，
没有亲身感受也就没法体会活在那个时代到底是一种怎样的经历。
只能从零零碎碎的文字间去窥见，去寻觅。

“ 雕像大约是在1967年建起的。那时候学校还叫华中工学院，这尊雕像就是学校铸造厂打造的。雕像是钢筋水泥浇筑的，有人误以为是石膏的，其实外面用的是白水泥，所以是白色的。年代久了以后，因为风雨侵蚀，增出现了水渍印子，后来重新整修了一下，镶嵌了大理石。”

“ 印象里，华科是武汉最早建起毛主席雕像的地方，也是最高大的一尊。此后武汉的一些厂子和机关，也都建起了不少毛主席雕像。”

再后来，别的地方陆陆续续都拆了，唯有华科的一直留存至今。

不管别人怎么去评论，我一直对这个雕像对历史持敬畏态度。
记得有次和实验室室友从外面回来，
路过雕像谈之，我表敬畏，他表不屑，
言毕，突然听他大骂一声，仰头捂鼻狂奔，原来是鼻血涓流不止，
我笑他，头上三尺有神明啊。
自此，再过雕像处，无不恭谨。

雕像背后靠着的是南一楼，算是华科老建筑里面标志性的建筑了，
也是承载了我两年来大部分记忆的地方了。
我是喜欢老建筑的，知道实验室在南一楼这老建筑里面，着实让我欢喜了一段时间。
走在里面，明显感觉到与近代建筑不同的沧桑和厚重感，
摸着剥落的墙壁前行，有种与历史交流的仪式感。
实验室在六楼，不大，也没有计算机系应有的科技感，
里面的杂乱和陈旧倒是和南一楼的沧桑相得益彰。

未完待续…