目录
前言
登录前端验证漏洞
忘记密码
给邮箱/手机发验证码
前端验证绕过
设置新密码时改他人密码
编辑 某网站密码找回功能
链接的形式-链接token参数可逆
服务端验证逻辑缺陷
登录状态下修改密码等验证条件
参数带用户名等多阶段验证
重置密码
重置后的默认密码
前言
今天我们接着逻辑漏洞的系列文章，接着来讲逻辑漏洞有关于登录前端验证漏洞
登录前端验证漏洞
忘记密码
给邮箱/手机发验证码
当在“忘记密码”页面，输入邮箱或者手机号后，网站会给手机或者邮箱发送验证码。用户输入验证码后，服务器会将其与正确的验证码进行对比，若相同则验证成功并进行下一步操作。网站还贴心的考虑 到了：万一用户手抖输错怎么办？有两个选择：
第一个：客户重新填验证码。网站本来想着用户这次能输对了吧，没想到用户不停的手抖输错，短信不 断的发到手机上（这是短信炸弹漏洞）。一条短信一毛钱啊，网站掏不起啊，那就试试方法2吧。
第二个：验证码再输一遍。在这种情况下，极易产生验证码爆破漏洞。
你可能会觉得输入一万条数据简直太漫长了，但是要知道我们发到网站服务器的都是数据包，验证码就 在数据包中。我们只要不断的修改数据包中验证码的参数即可完整验证尝试
攻击方法和图片验证码相似，如果是4位，没有多余的防御措施，直接爆破即可，案列如下
我们后台开启抓包：
将这个验证码添加payload
然后发送到Interuter模块：
前端验证绕过
客户端验证是不安全的，可能导致任意账号注册、登录及重置任意用户密码等一系列问题
1. 直接返回明文验证码输入手机号后，点击获取验证码。按 F12 调出开发者工具，然后在网络中，监听到两条 json 数据，可以发现本应该发送给用户的手机短信验证码就藏在 ticket 里面。用这个尝试登陆，输入 9360 即可登陆成功
2. 返回加密后的密码验证加密后，加密报文在应答数据包中，返回客户端，用户解密后即可获取验证码。
设置新密码时改他人密码
修改密码时可否修改参数（用户名/邮箱/手机）达到修改其他用户密码的目的。
首先在一个网站注册一个用户，然后修改这个用户的密码，通过抓取数据包中的参数判断哪里是校验用户，通过修改关键参数，达到任意修改其他用户密码的目的。
下面对一个网站进行模拟攻击，以便于在攻击中讲解能够更深刻的理解。
1. 先注册一个网站的账号，注销后在登录界面点击忘记密码。然后填写相应的信息，这里填写了刚才注册的用户名和密码。然后 开启浏览器的代理和 Burp 的截断，如下图所示。
2. 点击下一步后，分析报文，看到请求的报文中传递了用户名和邮箱，因此判断此数据包 是用来判断是否存在此用户、用户名和邮箱是否匹配的。点击 Forward 放过次数据包。
3、攻击者收到网站给的验证码（到这里都是正常的网站找回的逻辑）
4、继续填写验证码，发现还是没有什么可以利用的数据，放包过去
5、 到了修改密码的界面，填好密码后点击下一步。抓包后，观察发现这里写入了用户名和密码。
可以先右键报文，然后 Send to Intruder 之后可以爆破用户名，并将其修改为同 一个密码。不过这里只是测试一个叫 zhagnwei 用户名，这是我们之前爆破出的一个其他的用户，如下图所示
6、发送之后，发现修改成功（这里漏洞点：原因是没有对校正的账号和修改的账号进行匹配，导致可以先通过用户验证后，去修改别人的密码）
某网站密码找回功能
因为这种方式较为常见，因此再举一个例子，如下。 在用户更改密码和找回密码时，会发送一个验证码到手机。填写正确验证码后，后台会在返回的报文中通过状态码来进行正确的判断。
这个时候可以通过修改返回报文中的参数，使页面跳转到下一步认证的页面。
1. 在找回密码的界面，发现是通过填写手机号和返回的验证码进行身份认证。
2. 先填写一个想要修改的手机号，验证码随意填写一个。再打开浏览器代理和 Burp 的截断，这时候点击提交后，会抓取一个请求的数据包。
3. 这个时候可以拦截到回包， 观察图数据包中的 status 字段，这里的 0 可能是验证码错误的返回代码，因此我们尝试把他改为“1”，试试
4. 结果直接发发现已经可以输入新密码了
5、 填写密码后点击“确认修改”发现能够登陆， 说明任意用户密码修改成功
链接的形式-链接token参数可逆
通过邮箱找回密码时，邮件中将出现一个含有 token 的重置 URL，该 token 即为重置凭证。从经验来看，开发人员习惯以时间戳、递增序号、关键字段（如邮箱地址）等三类信 16 / 40 息之一作为因子，采用某种加密算法或编码生成 token，攻击者可以基于能收集 到的关键字段，用常见加密算法计算一遍，以判断是否可以预测出 token。下面举两个案例加以说明。
实验一：基于时间戳生成的 token ，这是一个靶场：
http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/
我们点击忘记密码：
来到当前页面：
输入用户名admin，点击重置密码，BP后台开启抓包
后台抓到的数据包：
我们将其发送给Repetaer模块：
我们看到username=admin的回显很正常：
接下来，我们把username这个字段改了看看会发生什么：
我们将其改为aaa后，他给我们返回了一段链接，注意看sukey这个字段后面的参数，像不像是我们平常接触的token。基于网站的信息，我们判断这是一个重置密码的链接，但是只有是aaa账户的情况下会出现这种情况，刚刚的admin账户并没有出现这种情况，那我们如果可以破解出这个重置链接的token加密方式，是不是可以通过伪造token来重置admin用户账户的密码了。
我们将这串key单独复制出来，根据经验判断，这很像是一串经过md5加密的key，我们将其拿到MD5网站解密试试看（MD5免费在线解密破解_MD5在线加密-SOMD5）：
解密出来之后是这么一串数字。发现是unix的时间戳（看多了，你就知道各种加密方式了），我们也可以将其放到时间戳的网站上验证看看（https://tool.lu/timestamp/）
好，现在我们确定了这串key的加密方式是时间戳在经过MD5的加密方式得到的，这下我们确定了攻击模型。虽然admin无法得知重置密码的链接，但是我们知道链接的构造，就可以模拟出来。
时间戳的值是根据一个时间数值递增的，比如现在的时间戳的值是123456，下一秒很可能就是123458，所以我们只要连续发送三次请求，得到一头一尾两个时间戳，便可以去爆破出中间的哪那个时间戳的值
攻击流程如下所示：
发送普通用户得到时间戳------>发送admin重置-------->在发送普通用户得到时间戳，那么admin的时间戳必定在两个用户的时间区间内，然后构造爆破语句爆破就可以了 。
我们回到我们重置密码的界面，BP后台开启抓包，分别输入用户aaa，admin，bbb，然后分别点击重置密码：
我们来到BP的后台，看看我们抓到的数据包：
接下来我们来收集三个数据包中响应的key值：
最终我们得到两个时间戳，然后将我们链接也复制上，因为等下要通过这个链接来伪造：
然后我们将两个tokenMD5解密，记录下来：
1672906019-1672906036，得到这么一个区间 ，admin既然在这个中间，那我们可以开始爆破，我们点击这个链接，抓到重置请求包，后开始加密爆破。
我们看到如下的数据包：
我们将这个数据包放到Inturder模块：
将我们要爆破的位置添加上payload，然后因为我们要爆破的是admin，所以我们要把username后面改为admin：
接下来来到payload模块添加我们的字典，设置如下：
然后我们再给他进行一个MD5加密处理：
然后开始我们的爆破：
有个长度异常的，应该是跑出结果来了：
然后查看一下我们的回包：
说明我们这个数据包成功重置了admin用户的密码。
实验二：基于关键字段生成的 token 某网站密码找回功能
通过分析，我们猜测1、username 是邮箱、rvcode 图片验证码、sid 未知，登录邮箱查看重置 URL：
2、重置的关键参数为key，直接丢到md5发现无法解密，后来发现多次尝试，发现md5(username + sid) 可以得到一个和邮件一样的MD5
3、 猜测出其 key 的生成算法，那么，后续将豪无压力重置任意账号的密码了。
服务端验证逻辑缺陷
登录状态下修改密码等验证条件
1、登陆状态下修改自己的密码时，通过修改截获的数据包，将部分参数替换，从而偷龙换凤的将他人的密码修改为自己指定的密码。下面通过实例讲解。
在登录状态下，点击修改密码。这个时候我们发现用户名变为不可修改的状态（当然我们可以通过修改前端的代码让这个用户名变为可以修改的状态）
不可修改就说明网站开发人员不想让用户修改用户名。这种情况常常出现随意修改其他用户密码的漏洞。
2. 这里抓取到数据包，观察数据包，数据包中包含用户名，旧密码和新密码。
3、将用户名修改成的其他的用户名
4、发现wangkaijiang的密码修改成功
参数带用户名等多阶段验证
密码找回流程一般包括获取短信验证码、校验短信验证码是否有效、设置新密码等三个步骤。
在第二步，校验短信验证码是否有效的结果应保存在服务端，某些网站未在服务端保存而是错误地将结果状态值下发客户端，后续又依靠前端 js 判断是否可以进入第三步。
那么，更改应答包中的状态值，可重置其他用户的密码。下面用两个案例分析说明。
案例一： 在密码找回页面 http://www.xx.cn/yy/action/forgot 用攻击者手机号 13908081024 进 入密码找回全流程，获取短信验证码 033128、输入图片验证码、输入短信验证码并提交：
服务端校验通过后，系统应答如下：
简单分析发现，校验通过时服务端并未向客户端 set-cookie，猜测服务端并未记录校验 状态，是否进入设置新密码页面完全是由前端 js 基于应答状态决定的，那么，即便我没有 短信验证码，通过将服务端下发给客户端的校验状态从“失败”改为“成功”。
也能成功重置找回账号密码。 具体而言，以信息搜集时找到的客服手机号 13980808888 为例。
输入手机号、获取短 信验证码、输入图片验证码、输入错误的短信验证码 123123 后提交：
拦截该应答，用前面抓取校验成功的应答包替换之：
这样又顺利进入新密码设置
案例二： 在密码找回页面 http://www.xx.cn/yy/forgot 用攻击者手机号 13908081024 进入密码找回全流程，获取短信验证码2118、输入短信验证码并提交：
简单分析发现，校验通过时服务端并未向客户端 set-cookie，将服务端下发给客户端的 校验状态 code 改为“0000”，可以重置其他用户密码。 具体而言，以土豪手机号 13888888888 为例。输入手机号、获取短信验证码、输入错误的短信验证码 1234 后提交。由于短信验证码错误，服务端校验失败，应答如下：
拦截后修改成0000即可进入设置新密码的环节 ：
重置密码
重置后的默认密码
在一些大型公司或者学校的的网站上，会有介绍用户注册的指导手册，里面会介绍用户的用户名和默认密码。
这时可以先用默认密码尝试爆破默认密码，或者寻找重置密码的选项，重置密码后，用默认口令尝试登陆。 因为可能会有未授权修改网站用户的密码。
