渗透测试业务逻辑之密码找回测试

0x00：前言

上周做渗透，有一个 sql 注入，负责安全审核的人给开发说你们的程序既然还有 sql 注入，我一年也看不见几个。这句话让我又再次深刻的认识到，渗透测试常规的一些注入跨站漏洞不如以前那么盛了，有点经验的开发写东西都会去考虑到了，再加上修复方法也在逐渐的完善，逻辑类的东西也应该并重的去测。

0x01：分类

我把逻辑类的问题大概总结了一下，大概可以分为十个模块，分别是登录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入 / 输出模块测试、回退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块测试、业务接口调用模块测试。

这次记录的是第九个模块密码找回模块测试。

0x02：密码找回模块测试

1，验证码客户端回显测试

测试方法：在很多的修改密码功能中，第一步都会要求用户输入手机号或者邮箱来验证用户的身份，那么验证码就可能会出现在响应包中，有些程序会将验证码放在响应包中。拦截发送验证码的的请求，查看其 response 的信息，是否包含其验证码，包含验证成功，则存在此问题。

修复方法：避免将验证码回显在响应包中，验证的比对应放在服务端进行。

2，验证码暴力破解测试

测试方法：一般情况下，只有用户自己通过手机或邮箱来收取验证码，但当服务器没有对错误的次数做限制时，则可导致暴力破解。首先应该知道验证码的规律，例如是 4 位数字，或 6 位数字，然后手机发送验证码后，任意输入一个符合规则的验证码，拦截包发送到 intruder，对验证码添加标记进行枚举测试，跑出结果后根据 length 长度来找出正确验证码。

经验之谈：有时候可能会碰到这样的情况，就是枚举时，如果选择的 number，则配置 1111 到 9999 时，以 0 开头的验证码会匹配不到。选择 brute forcer 时，出现问题不能用时。可以导入外部的字典文件，建议存一个四位数验证码字典和六位数字段，测试会经常用到。number 不建议，不合适，建议使用 burte forcer，如果不行，就退而求其次使用外部字典。

修复方法：建议对错误的次数做限制，避免被爆破，同时设置验证码的有效期，然后再加大其复杂度。

3，接口参数账号修改测试

测试方法：这个也可以分为多种情况，例如修改密码时，需要发送用户凭证，拦截数据包，将凭证的地址（手机号或者是邮箱等）改为自己的，如果自己可以收到，则存在此问题。再例如，直接修改自己的，拦截数据包，将其中修改的账号换成他人的，如果成功修改，则也存在此问题。

修复方法：建议对修改连接增加 token 来做验证，一个 token 只能修改一次且 token 只能使用 1 次。

4，response 状态值修改测试

测试方法：例如一个修改密码功能，第一步需要输入手机号和接收到的验证码，通过后才可以进行第二步的修改。通常如果第一步验证成功，一般服务器都会返回类似 ok、1、success、true 这种的状态值。那么在拦截数据包后可以右键选择 do intercept->reponse to this request，这样下一步就会显示服务器的返回包，修改其状态值，然后直接 intercept is on 关闭拦截数据包，如果跳转到修改密码页，则存在此问题。

修复方法：前端不要利用服务器的返回值来判断是否修改密码，在整个校验的流程中，都应该在服务器进行。

5，session 覆盖测试

例如一个修改密码的功能，第一步需要输入手机号，然后验证下验证码，跳到第二步，重置密码页。session 覆盖测试第一步：输入自己的手机号和自己的短信验证码跳到密码重置页，打开一个新的标签页，粘贴密码重置页的 url，放在这里做备用。第二步：回到刚才输入自己手机号的那个页面回退一步，此时输入目标用户的手机号，然后发送验证码。第三步：目标用户不知道有没有收到验证码，但此时的 session 已经有自己的换成了目标用户的。第四步：打开刚才备用的那个重置密码页，刷新一下，如果有显示修改的账号手机号，则此时应该会变成目标的手机号。重置后可以成功修改目标用户的密码。则存在此问题。

经验之谈: 上述可能比较啰嗦，其实就是先获取第二步的密码重置页，然后重新给目标手机号发送验证码，以此来替换 session，这样第二步的密码重置页才能重置目标用户。当数据包的一些参数无法修改时或者是服务器通过 session 来判断用户身份时，则可以使用此方法测试。

修复方法：在重置密码的请求中，一定要对修改的账号和凭证是否一致做进一步的校验。

6，弱 token 设计缺陷测试

测试方法：很多密码找回功能都会将重置密码链接发送到邮箱，可以发送多次，然后观察其 url 的规律，很多网站的重置密码链接的 token 并不安全，例如使用时间戳作为 token，或者是 id 经过 md5 作为 token，或者是 base64 编码后作为 token，观察规律后就可以伪造 url 进行目标用户的重置，如果中间加油随机数，则可以暴力破解下。

修复方法：建议设置 token 的复杂度，不要有规律可循，如果加随机验证码，建议位数多点。同时 token 设置失效时间，避免恶意攻击者有足够的时间进行爆破。

7，密码找回流程绕过测试

测试方法：当找回密码分为多步时，例如一步输入账号页，第二步验证身份页，第三步修改密码页。可以先用自己的账号走一遍流程，把每一步的流程都拦截数据包，依次记录下整个过程中所有的 url，然后直接访问第三步的 url 页面地址，如果可以成功打开并修改，则存在密码找回绕过问题。

修复方法：建议在后台要验证上一步的操作是否已经完成，避免被绕过。

0x03：总结

这个中有很多测试方法和之前的验证码模块很相似，例如爆破、回显等，很多方法都可以通用，学会思路是最重要的。

这次总结了第九个模块密码找回模块测试的一些方法，后续会继续记录其他模块。

公众号回复数字“8”领取CIS加固全套手册。

微　信：fageweiketang，朋友圈不定期干货分享，欢迎讨论。

公众号：发哥微课堂，专注于代码审计、WEB渗透、网络安全。