对某P2P行业的app进行了部分安全功能测试，主要测试密码找回部分的逻辑。该平台目前投资额已近百亿，在各大网贷评级机构上均在前30名内，也算规模不小的了。

一、正常找回密码流程，记录过程中数据包

0x01 正常找回密码流程

第一步：用户输入手机号码和图形验证码后，发送手机短信

第二步：用户输入短信验证码后进入密码修改页面

第三步：用户输入短信验证码后进入密码修改页面

0x02 过程中记录的数据包如下

第一步：发短信

第二步：验证短信验证码

第三步：修改密码

0x03 分析过程的参数及对应关系

如图所示：

第一步（M2006）：请求里参数包括content和token，其中tontent为手机号。响应中的信息包括sign、msg、token等；

第二步（M2007）：请求里的参数包括第一步响应里的sign、token以及短信验证码和手机号。响应中包括msg、token等；

第三步（M2008）：请求中包括第一步响应中的sign、第二步响应中的token以及短信验证码、手机号和密码密文信息等；

整个找回密码过程中按请求分成三部分M2006、M2007、M2008。共生成1个sign、4个token信息，并以req、res进行命名。以下分别分析三个过程中会有哪些问题。

二、分析三个过程

0x01 M2006过程，发送短信验证码

请求中只有手机号和token信息，因此对手机号输入进行，测试结果如下：

测试结果：

1、发送短信验证码可使用任何手机号码生成请求中的token；
2、每次请求即使参数一样，响应中生成的sign和token都不一样；
3、每个手机号每天可发送的短信数为30个；

0x02 M2007过程，验证短信验证码

请求中有sign、code、mobile、token信息，对其中几个的对应关系进行测试，测试如下：

测试结果：

1、同一个验证码只能使用一次；
2、只有最新一次的验证码可用，即使上次验证码并没有使用；

3、sign和code有对应关系；
  a、code输入错误，提示验证码输入错误；
  b、sign输入错误，提示验证码输入错误；
  c、只有都输入正确，才能验证成功；

4、token和本次请求没有对应关系，即可以使用任何服务器验证有效的token，比如上次token、请求中的token、其它手机号生成的token等；

0x03 M2008过程，重置密码

请求中有sign、code、mobile、token、passwd信息，针对sign、token、passwd进行测试，测试如下：

测试结果：

1、token可以使用整个重置密码过程中的token，比如请求中的、响应中的，其它手机号生成的，只要是生成的token在服务器上存在就行；
2、重置密码过程中只验证token本身有效性，不验证token与账户的关系；
3、重置密码过程中短信验证码可重复使用，只要验证码不过期；
4、重置密码过程可跳过M2007步骤，直接使用M2008请求重置；

5、code和sign有对应关系，必须保持一致才能重置成功；
6、多次生成的短信验证码，都可以用来重置密码，这点和M2007中不同；
7、短信验证码有效期大概为15分钟；

三、有哪些漏洞

根据以上分析过程，有以下漏洞

1、根据响应不同，可批量获取系统中的注册用户（手机号），系统在这里没有控制措施（M2006）；

2、短信轰炸，或者拒绝服务，使用户当天无法重置密码（M2006）；

3、重置密码过程中，M2007步骤可跳过，控制措施失效（M2008）。

4、token本身控制作用失效，按系统的设计逻辑，后一步请求中的token来自于前一步响应，但是这里实际上只要token在服务器中存在就可以通过验证（M2006、M2007、M2008）；

5、重置密码的最终请求可以重放（M2008）；

6、最后的修改密码请求需要知道sign、code、mobile、token、passwd信息，其中：

sign：M2006中生成：任何人都可以获取

code：M2006中生成：号码主人获取

mobile：任何人可以获取

token：M2006、M2007、M2008中生成；任何人都可以获取

passwd：M2008中生成，同一密码密文相同：任何人都可以获取

由于重置密码请求可以重放，并且因为sign、token、passwd信息任何人都可以获取，可以使用暴力破解6位数字短信验证码的方式直接修改账户密码为已知密码。