目录

1.服务端验证逻辑缺陷

1.1 下面通过实例分析：

1.1.1 step1

1.1.2 step2

 1.1.3 step3

 1.1.4 step4

2.参数带用户名等多阶段验证

2.1 案例分析（一）

2.1.1 Step1

 2.1.2 Step2 

 2.1.3 Step3

 2.1.4 Step4 

 2.1.5 Step5

 2.1.6 Step6

2.2 案例分析（二）

2.2.1 Step1

 2.2.2 Step2

2.2.3 Step3

 2.2.4 Step4

3.重置密码﹣重置后的默认密码

---

1.服务端验证逻辑缺陷

• 登陆状态下修改自己的密码时，通过修改截获的数据包，将部分参数替换，从而偷龙换凤的将他人的密码修改为自己指定的密码。

1.1 下面通过实例分析：

1.1.1 step1

在登录状态下，点击修改密码。这个时候我们发现用户名变为不可修改的状态（当然我们可以通过修改前端的代码让这个用户名变为可以修改的状态）

不可修改就说明网站开发人员不想让用户修改用户名。这种情况常常出现随意修改其他用户密码的漏洞。

1.1.2 step2

我们用BP抓包，分析数据包，发现了用户名、新密码和旧密码

 1.1.3 step3

将用户名改为其他用户

 1.1.4 step4

发现wangkaijiang密码修改成功

2.参数带用户名等多阶段验证

        密码找回流程一般包括获取短信验证码、校验短信验证码是否有效、设置新密码等三个步骤。

        在第二步，校验短信验证码是否有效的结果应保存在服务端，某些网站未在服务端保存而是错误地将结果状态值下发客户端，后续又依靠前端 js 判断是否可以进入第三步。
        那么，更改应答包中的状态值，可重置其他用户的密码。

2.1 案例分析（一）

2.1.1 Step1

        在密码找回页面http://wwW.XX.cn/yy/action/forgot用攻击者手机号139G8081024进入密码找回全流程， 获取短信验证码033128、输入图片验证码、输入短信验证码并提交：

 2.1.2 Step2 

服务器效验后，系统会有响应

 2.1.3 Step3

        简单分析发现，校验通过时服务端并未向客户端 set - cookie ，猜测服务端并未记录校验状态，是否进入设置新密 完全是由前端 js 基于应答状态决定的。
        那么，即便我没有短信验证码，通过将服务端下发给客户端的校验状态从“失败”改为“成功”也能成功重置找回账号密码。具体而言，

        以信息搜集时找到的客服手机号139808X8888为例：输入手机号、获取短信验证码、输入图片验证码、输入错误的短信验证码123123后提交：

 2.1.4 Step4 

我们随便输入一个验证码，肯定会报错的

 2.1.5 Step5

拦截响应，用之前抓取效验成功的数据包替换

 2.1.6 Step6

顺利进入新密码设置

2.2 案例分析（二）

2.2.1 Step1

在密码找回页面http://wwW.XX.cn/yy/forgot用攻击者手机号13x080810x4进入密码找回全流程，获取短信验证码2118、输入短信验证码并提交：

 2.2.2 Step2

服务端通过效验后，会有如下应答：

        简单分析发现，校验通过时服务端并未向客户端 set - cookie ，将服务端下发给客户端的校验状态 code 改为“0000”，可以重置其他用户密码。

2.2.3 Step3

        具体而言，以土豪手机号13888888888为例。输入手机号、获取短信验证码、输入错误的短信验证码1234后提交。由于短信验证码错误，服务端校验失败，应答如下：

 2.2.4 Step4

我们把9999改为0000,发现通过校验

3.重置密码﹣重置后的默认密码

• 在一些大型公司或者学校的的网站上，会有介绍用户注册的指导手册，里面会介绍用户的用户名和默认密码。
• 这时可以先用默认密码尝试爆破默认密码，或者寻找重置密码的选项，重置密码后，用默认口令尝试登陆。
• 因为可能会未授权修改网站用户的密码