【业务安全实战演练】密码找回模块测试08

发布时间 2023-12-20 23:19:39作者: 橙子全栈测试笔记

一、验证码客户端回显测试

典型场景:

  任意用户登录
  使用验证码的场景:

人机验证:防止机器操作,爆破表单。
唯一凭据:唯一性判断,任意账户登录。
​   找回密码测试中要注意验证码是否会回显在响应中,有些网站程序会选择将验证码回显在响应中,来判断用户输入的验证码是否和响应中的验证码一致,如果一致就会通过校验。

二、验证码暴力破解测试

  密码找回凭证是指在密码找回过程中,服务器向用户的注册手机或者邮箱中发送验证码或特殊构造的URL等用于用户自证身份的信息,当用户凭证的验证次数未做限制或限制不严可被绕过时,攻击者可以通过暴力破解枚举用户凭证的方式冒充该用户重置密码。

 

三、接口参数账号修改测试

找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账号的参数,而用户账号参数作为一个可控的变量是可以被篡改的,从而导致修改账号密码的凭证或修改的目标账号出现偏差,最终造成任意账号密码修改的漏洞

测试流程
接口参数账号修改测试流程为拦截前端请求,通过修改请求内邮箱或手机号等参数,将修改后数据发送给服务器进行欺骗达到密码重置的目的,如图所示。

 

步骤一:在某网站的找回密码功能中,当输入用户账号后会出现发送重置密码邮件的按钮。在单击发送按钮时抓包,可以看到用户的邮箱已经出现在了数据包的email参数值中,那么尝试将email参数修改为我们自己的邮箱会出现什么情况?如图所示。
步骤二:修改email参数的值后,网站提示邮件已经发送成功,此时可以打开我们自己的邮箱查看修改密码邮件是否收到,

四、respone状态值修改测试

Response状态值修改测试:
测试原理和方法:
  修改请求的响应结果来达到密码重置的目的存在,这种漏洞的网站或者手机APP往往因为校验不严格,导致了非常危险的重置密码操作。
  这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后,出现特定的响应值,比如true,1,ok,success 等值,网站看到回显内容为特定值后就可以修改密码,通常这种漏洞的回显时校验是在客户端进行的,所以只需要修改回显值即可。
测试过程:
Response状态值修改测试流程主要是分析服务端校验后的结果,正确和错误分别是什么样的返回结果,通过修改返回结果为正确来欺骗客户端,以达到密码重置的目的。
  第一步:找到某网站的返回密码功能,输入要找回的目标手机号,短信验证码可以随便输入,然后点击 “ 找回密码 ” 按钮并对该请求进行抓包(Burp Suite )
  第二步:可以看见这个请求包含有 validateCode(验证码) 和 phone(手机号)两个参数,然后在 Burp Suite 抓包页面中右击 ,选择Do intercept --> Response to this request -- >放包,后就可以看到这个请求的回显包了
  第三步:然后就可以看到 Response 回显包已经成功接收到了,但是包返回的值是 false,通常 false 是失败的含义,也就是说服务器端校验验证码的时候发现验证码不一致然后返回了 false 给客户端,然后在这里我们尝试一下把 false 修改为 true ,然后点击 Intercept is on 按钮关闭拦截让数据包正常发送。
  第四步:接着我们可以看到页面直接跳转到密码重置页面.
修复建议:
注意不要在前端利用服务器端返回的值判断是否可以修改密码,要把整个校验环节交给服务端进行验证.

五、Session覆盖测试

Session ID 也叫会话ID,服务器对浏览器客户端用户身份进行唯一性标志。

找回密码逻辑漏洞测试中也会遇到参数不可控的情况,比如要修改的用户名或者绑定的手机号无法在提交参数时修改,服务端通过读取当前 session 会话来判断要修改密码的账号,这种情况下能否对session 中的内容做修改以达到任意密码重置的目的呢?

在某网站中的找回密码功能中,业务逻辑是:由用户使用手机进行密码重置,然后服务端向手机发送验证码短信,用户输入验证码提交后,进入密 码重置页面。

对网站中Session 覆盖的测试如下:

  • 打开浏览器,访问重置密码页面,并提交自己的手机号(133),同时浏览器接收Session ID;
  • 用自己的账号(手机号,133)接收凭证(短信验证码);
  • 获得凭证校验成功后,进入密码重置页面;
  • 在浏览器新标签重新打开找回密码页面,输入目标手机号(177),此时服务器就会重新下发Session ID;
  • 此时当前SessionID 已经被覆盖,重新回到第三步中打开的重置密码页面即可重置目标手机号密码。

漏洞原因:

  • 在验证码校验之后,没有及时更新Session ID,或者没有及时更新服务器端SESSION 信息。
  • SessionID 不仅要与手机号绑定,还要与验证码绑定

六、弱Token设计缺陷测试

在找回密码功能中,很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱,打开找回密码邮件中的链接,就可以进入密码重置页面了。找回密码的链接通常会加入校验参数来确认链接的有效性,通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效。
测试流程
步骤一:在类似的接收凭证方式的密码找回功能中,填写邮箱或者手机号,多单击几
次发送验证信息,可以在邮箱中获得多个找回密码的凭证,如图

发送验证信息

接收多个找回密码邮件

步骤二:邮箱中收到多封密码找回邮件,观察链接中的密码找回凭证是否有规律可
循,以下列出几个找回密码的链接。
第一封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz
dEAxMjYuY29tJjk5NTk=
第二封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz
dEAxMjYuY29tJjI2ODI=
第三封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz
dEAxMjYuY29tJjk4NzY=
步骤三:通过对比发现Token参数在不断地变化,参数似乎是通过base64编码的,对
此可以对这三个链接中的Token参数做base64解码操作,结果如表所示

步骤四:解码后可以发现每一个Token的值是可以预测的,Token的生成机制应该是“base64编码(用户邮箱+随机4位验证码)”,这样就可以通过暴力枚举获得验证码,加上用户名再进行base64编码,最后得到任意用户的密码找回凭证。 

七、密码找回流程绕过测试

使用自己的账号使用正常顺序流程找回密码成功,我们也获取到了三个
步骤的所有URL,最后整理如下。
(1)GET/account/findPassword.html//输入用户账号页面
(2)GET/forgetpwd/findPassNext.do//验证身份页面
(3)GET/forgetpwd/emailValidateNext.do//设置新密码页面
接下来可以尝试在第一步输入账号后进入第二步验证身份页面,在这个页面直接修改
URL为第三步的URL,访问看看是否可以直接进入密码重置页面,如图

经过测试以后发现不需要验证身份可以直接进入重置密码页面,如图 所示,那么最重要的验证身份这一步就被轻松绕过了

修复建议
防止跳过验证步骤一定要在后端逻辑校验中确认上一步流程已经完成。

八、删除参数绕过验证

第一步:某邮箱系统可以通过密码提示问题找回密码.

第二步:首先随机填写密码答案,然后进入下一步抓包后将问题答案的整个字段都删除再提交.

第三步:因服务端验证逻辑存在缺陷,无法获取到问题答案的情况下,直接通过了验证密码重置成功.

参考链接:https://tianyuk.blog.csdn.net/article/details/130117325?spm=1001.2014.3001.5502