【业务安全03】密码找回业务安全以及接口参数账号修改实例（基于metinfov4.0平台）

本文链接：https://blog.csdn.net/m0_64378913/article/details/125456410

1 密码找回安全测试

1.1 验证码方面

1.1.1 验证码客户端回显测试

业务背景：用户登录或密码找回时，需要根据一个图片输入验证码，有些网站程序会选择将验证码回显到响应中，来判断用户输入的验证码是否和响应中的验证码一致，如果一致就会通过验证。

测试方法：找回密码测试中要注意验证码是否会回显到响应（更多指的是网页代码）中，如果回显到响应中，则认为有漏洞。

危害：可能会包抓包用于爆破。

1.1.2 验证码暴力破解

业务背景：找回密码功能模块中，通常会有将用户凭证（验证码）发送到用户自己才可以看到的手机号或者邮箱中，只要用户不泄露就不会被攻击者利用，但是有些应有程序在验证码发送功能模块中验证码的位数及复杂性较弱，也没有对验证码次数限制而导致验证码可以被暴力枚举并修改任意用户密码。

测试方法：在测试验证码是否可以被暴力枚举时，可以先将验证码多次发送给自己的账号，先观察验证码是否有规律，再观察是否有对验证码的尝试次数进行限制，如果密码规律简单且没有次数限制就容易被爆破。

1.1.3 验证码重复利用

业务背景：用户登录或密码找回时，需要根据一个图片输入验证码，一般情况下，客户端在登录界面输入账号密码验证码并提交，如果成功就进入下一个页面，如果失败就刷新页面（此时验证码因刷新页面而刷新）重新输入。也就是如果服务端在接收到请求后没有自动刷新验证码，就存在客户端不刷新页面就不会刷新验证码的情况，此时就存在验证码重复利用的漏洞。

测试方法：在测试验证码是否可以被重复利用时，可以用BurpSuite抓一下登录的请求包，发送到Repeater模块中重复发送请求（在BurpSuite中发送请求不会刷新页面），看看第二次发送请求时是否会提示验证码出错，来判断是否存在验证码重复利用的逻辑漏洞。

危害：可能会包抓包用于爆破。

1.2 Cookie、Session、Token方面

1.2.1 Session 覆盖

业务背景：密码找回业务中也会遇到参数不可控的情况，比如说要修改的用户名或者绑定的手机号无法在提交参数时修改，服务端通过读取当前Session会话来判断要修改密码的账号，这种情况下能否对Session中的内容做修改以达到任意面重置的目的呢？

有些网站中找回密码功能中，业务逻辑这样的：

由用户使用手机号进行注册；
然后服务端向手机发送验证码短信；
最后用户输入验证码提交后，进入密码重置页面。

Session覆盖测试步骤如下：

需要准备自己的账号接受凭证（短信验证码）；
获取凭证校验成功后进入密码重置页面；
在浏览器新标签中重新打开找回密码页面，输入目标手机号；（待攻击对象）
获得攻击对象的SessionID，重新回到第二步中打开的重置密码页面，并将攻击对象的SessionID覆盖掉自己的SessionID，那么重置密码可能是重置攻击目标的密码。
如果回到第二步能成功修改密码则表明存在逻辑漏洞；如果弹出要求输入验证码则说明服务端会对当前Session是否已经进行验证进行校验。

1.2.2 弱Token设计缺陷测试

业务背景：在找回密码功能中，很多网站会向用户邮箱发送密码页面连接，用户只需要进入邮箱，打开找回密码邮件中的链接，就可以进入密码重置页面了。

找回密码的链接通常会加入校验参数来确认链接的有效性，通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效，比如http://www.xxx.com/findpwd?uid=xx-uu-sxx&token=xxxxxx。而如果Token值设计得比较弱，我们也可以进行爆破

1.3 Response 状态值修改测试

概述：Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或手机APP往往因为校验不严格而导致非常危险的密码重置操作。

测试方法：在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true、1、ok、success等表示对错的值，网站看到回显内容为特定值后就会修改密码，通常这种漏洞的回显值校验是在客户端进行的，所以只要修改回显即可。

1.4 密码找回流程绕过测试

用户修改密码需要向服务器发送修改密码请求，服务器通过验证后再修改数据库中相应的密码。密码找回常规步骤：

用户输入找回密码的账号。
校验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单机链接进入密码重置页面，以此方式证明当前操作时账号主人。
校验成功进入重置密码页面。

在上述业务逻辑步骤中，第二步校验凭证尤为重要。不是账号主人，是无法收到校验凭证的，试想是否存在一些方式绕过第二步直接进入第三步重置密码呢？
用户修改密码需要向服务器发送修改密码请求，服务器通过验证后再修改数据库中相应的密码，所以在测试中，我们首先要收集三个步骤的请求接口，重点是收集最后一步重置密码的接口，这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。

1.5 接口参数账号修改

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

接口参数账号修改测试为拦截前端请求，通过修改请求内的账号ID、名称或邮箱、手机号等参数，将修改后的数据发送给服务器进行欺骗以达到密码重置的目的。

例子：以metinfov4.0为例

2 接口参数账号修改实例—基于metinfov4.0平台

2.1 实验目的

加深对业务数据安全重要性的理解；
掌握在密码重置业务中，测试通过接口参数修改导致密码重置漏洞的方法。

2.2 实验环境

2.2.1 实验靶机

实验靶机——虚拟机：本节实验靶场是虚拟机中安装的win2008及phpstudy，安装过程可以参考《《【语言环境】WAMP环境部署及优化—以win2008R2SP1为操作系统》》。

攻击机：真实机。注意靶机与攻击机处于同一局域网。

2.2.2 搭建metinfo4.0靶场

搭建metinfo4.0靶场的步骤如下：
（1）下载metinfo4.0版本。下载网址为https://zhuanlan.zhihu.com/p/45722772。
在这里插入图片描述
（2）解压并复制文件夹到靶机中的网站根目录下。不同版本的phpstudy软件的安装时生成的目录可能存在差异，本文metinfo4.0路径如下。

（3）真实机浏览器输入172.16.1.1/metinfo4.0访问metinfo，页面上弹出警告，无需理会，滑到最下方点击同意许可。
在这里插入图片描述
（4）进入第二步，全部选项均为绿色通过，点击安装。

（5）设置数据库信息，并点击继续。
在这里插入图片描述
（6）看到全部为绿色，点击进入管理设置。

（7）设置管理员账户，此处仅为做实验，账户设置为admin，密码设置为123456，并点击保存。

（8）安装成功，点击进入网站。
在这里插入图片描述

2.3 实验步骤

（1）真实机打开火狐浏览器，访问上述网站172.16.1.1/metinfo4.0。进入网页下方的会员中心。
在这里插入图片描述
（2）注册账户。进入注册页面，新建一个账号aaa、密码均为111111，点击立即注册。

（3）登录账户。登录账户aaa，页面如下。
在这里插入图片描述
（4）重置密码。点击左侧修改基本信息栏目，将密码修改为123456，暂时不点提交。

（5）真实机打开BurpSuite，进入proxy模块，将BurpSuite的代理拦截功能打开；回到浏览器，打开代理模式，并再将上述页面点击“提交信息”，可以看懂BurpSuite拦截到请求如下，在该请求中我们看到了账户及要修改成的密码。BurpSuite的操作可具体参考《【Burp Suite工具-2】BurpSuite工作原理及菜单栏介绍》
在这里插入图片描述

（6）修改用户aaa的密码。将请求中的密码修改为654321→并点击forward。
在这里插入图片描述
（7）验证用户aaa的密码是否修改成功。回到浏览器中，我们看到弹出窗口说操作成功，点击确定后，重新登录账号aaa，密码为654321，登录成功，说明用户aaa的密码修改成功。

（8）将用户aaa的用户名替换为admin。登录aaa账号，重新进入修改密码的页面并提交请求，并用BurpSuite拦截该请求，在BurpSuite中将请求中的useid字段修改为admin，点击forward。
在这里插入图片描述

（9）验证是否修改了admin的密码。

1）回到浏览器中，看到操作成功，但是此时aaa账户并没有掉线，说明修改的并不是aaa的密码。
2）浏览器访问http://172.16.1.1/metinfo4.0/admin进入管理员界面，尝试用原来的账号admin密码123456,登录，发现登录失败；尝试新的密码登录，用户admin密码654321，发现登录成功。说明上述步骤中修改的是admin的密码。这就是接口参数被篡改导致密码重置的漏洞。

注意，在挖洞时，可以注册两个用户，在两个用户间进行修改。