|
1、验证码不失效（验证码爆破） 产生原因：会话缺少对验证码检验功能失郊。 利用方法：通过枚举进行验证码爆破，取值范围:000000-999999，Burp可以实现这个功能。 2、验证码直接返回在数据包中 产生原因：输入手机号后点击获取验证码，验证码在前端生成，并直接返回在Response包中。 测试方法：输入任意手机号，点击获取验证码，并观察返回包，在返回包 中直接得到目标手机号获取验证码。 3、验证码没有绑定用户 产生原因：输入手机号和验证码进行重置密码的时候，仅对验证码进行了判断，未对该验证码是否与手机号匹配做校验。 测试方法：在提交手机号和验证码的时候，替换手机号为他人手机号进行 测试，成功通过验证并重置他人密码。 例如：用户A的手机号是18812341234验证码：123456。用户B的手机号 是13867896789，当在重置密码过程中，利用A的手机号进行收验证码，接收到验证码后进行改包，把A的手机号改成B的手机号，验证码不变。 4、修改接收验证码的手机或邮箱 产生原因：用户名、手机号、验证码三者没有统一进行验证，仅判断了三者中其中的手机号和验证码是否匹配正确，如果正确则判断成功并进入下一步。 测试方法：输入用户名获取验证码，修改接收验证的手机号为自己的号 码，将接收到的验证码提交进行验证。 5、本地验证绕过 产生原因：由于系统在前端进行校验，导致可在数据包更改参数值，然后发送请求，服务器误以为已经输入了正确的验证码。 测试方法：输入错误的验证码，修改返回包中的参数值，既可绕过验证。 6、跳过验证步骤 产生原因：对修改密码的步骤，没有做校验，导致可以直接输入最终修改 密码的Url，直接跳转到该页面，然后输入新密码达到重置密码的目的。 测试方法：首先使用自己的账号先测试，把重置密码步骤Url做记录，然后重置他人用户时，直接输入修改新密码的Url。
7、未校验用户字段的值 产生原因：在整个重置密码的流程中，只对验证码和手机号做了校验，未对后面新密码设置的用户身份做校验，导到在最后一步通过修改用户身份来重置他人的密码。 测试方法：使用自己的手机号走流程，在最后一个设置新密码的流程时候，修改数据包里的用户信息。
8、修改密码处ID可替换 产生原因：修改密码的时候，没有对原密码进行判断，且根据ID的值来修改用户的密码，类似SQL语句:update user set password = '123qwe' where id ='1'修改数据包里的ID值，既可修改他人的密码。 测试方法：修改自己的用户密码，抓取数据包，替换数据包中的用户对应的ID值，即可修改他人的密码。
9、cookie值的替换 产生原因：重置密码到最后一步的时候，仅判断用户的Cookie是否存在，并没有判断该Cookie有没有通过之前的重置密码过程的验证，导致可替换Cookie重置他人的用户密码。 测试方法：重置自己用户密码到达最后阶段，抓到数据包，并在第一阶段重新获取目标用户Cookie，替换Cookie到抓取的数据包中发包测试。
10、修改信息时替换字段值 产生原因：在执行修改信息的时候，用户的密码也当作字段执行了，而且是根据隐藏参数loginid来执行的，这样就导致修改隐藏参数loginid的值，就可以修改他人的用户密码。 测试方法：修改个人资料的时候，抓取数据包，然后来修改数据包的参数和对应的值，参数名一般可以在其它地方找到，替换隐藏参数即可修改他人的密码信息等。
|
|
|
来自： 昵称27086148 > 《IT》
