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

男娘i 2022-05-17 10:15 246阅读 0赞

## **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：总结** ##

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

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

--------------------

**                                                                        公众号推荐：aFa攻防实验室**

**分享关于信息搜集、Web安全、内网安全、代码审计、红蓝对抗、Java、Python等方面的东西。**

![20191220230427373.jpg][]

[20191220230427373.jpg]: /images/20220517/faca0b9cca474c94b470128a7cbb7e85.png