前记

• 今天是学习小迪安全的第七十四天，本节课主要内容是关于验证码机制的，常见的三种验证方式就是手机验证码、短信验证码、短信验证链接，这里讲了如何去尝试绕过他们的几种方法
• 主要以理解绕过思路为主，当然也需要下去自己复现理解思路逻辑
• 所需要的靶场资源已放至下方链接，需要自取：
  • https://pan.baidu.com/s/1YSjyW4ehxfDrqeeWjEXsSA
  • 提取码：gaii

WEB攻防——第七十四天

机制验证篇&重定向发送&响应状态码&跳过步骤&验证码回传&枚举

验证码突破 - 回传显示&规律爆破

漏洞原理

• 回传显示这个完全是属于开发者设计失误，将验证码回显到数据包中，导致攻击者能够直接得到验证码，绕过
• 而规律爆破这里，主要是验证码校验时位数有限或者规律可知，并且验证码存活时间长、没有提交次数限制，导致攻击者可以通过爆破枚举的方式绕过

案例演示

回传显示

• 这里之前碰到过一个真实案例，直接将验证码回显到数据包中，能够直接绕过：
  

• 但是现在这种例子应该比较少了，gay迪上面演示的例子应该也是很早之前的例子了

• 首先找到发送验证码的页面，然后抓包：
  
  

• 发现验证码就直接回显在数据包中，那这时就直接绕过了

• 或者有些不是直接回显，而是你输入错误的验证码，服务器回显正确的验证码：
  

• 反正都可以测，这种漏洞也是越来越少了

规律爆破

• 这里福利期货APP应该是没了，不知道为什么我这边模拟器打不开，那我们就理解这个思想就好了

• 其实就是响应包中附带自己提交的验证码值，然后利用BP去爆破：
  

• 看哪个成功就直接用，不过现在都是6位验证码，而且规定了时间，所以基本是很难爆破了

验证目标 - 重定向发送&重定向用户

漏洞原理

• 重定向发送就是尝试将本来发送给别人的验证码发送到我们自己这里，造成绕过
• 重定向用户就是我们自己接收验证码，然后提交时将用户换成目标用户，造成绕过
• 核心都是尝试将验证码发送给我们自己，只不过更改的步骤不同，相当于正常接收验证码的步骤是：

用户填入正确电话/邮箱 -->  发送验证码  -->  接收验证码  -->  进入下一步操作

• 重定向发送是在第一步到第二步之间，而重定向用户是在第三步到第四步之间

案例演示

重定向发送

• 这里演示的案例是MetInfo，搭建环境为PHP5.4，MySQL5.7，搭建教程略过

• 我们需要先配置一下邮箱设置，登录到后台，然后点击设置，找到邮件发送设置，填入相应的信息：
  

• 注意密码填入的是邮箱的授权码，不知道怎么获取授权码的可以上网查一查，这里我用的是163邮箱，然后是在这里获取的授权码：
  

• 好，我们退出登录重新来到后台登录页面，选择忘记密码，使用电子邮箱找回，然后输入自己用户名或电子邮箱：
  

• 点击下一步抓包：
  

• 这里是有一个met_host参数可以传入的，他可以将服务器发送数据包的地址修改为自己的，如 nc 监听的一个端口

• 这里在自己的服务器上开启监听，然后发包，按道理来说是能够成功的，但是我本地是没有复现成功，如果成功接收是这样：
  

• 然后点击链接就可以重置别人的密码了

• 这里给我们的启示就是如果数据包中出现这样的参数，我们可以尝试修改为自己，让他的流量经过我们本地

重定向用户

• 这里演示案例是EyouCMS，搭建环境为PHP7.3，MySQL5.7，搭建教程就略过了

• 然后我们配置一下电子邮件，登录到后台，然后选择接口配置，找到电子邮件配置，同样填入相应的信息即可：
  

• 配置好之后，我们先注册两个用户：

+ 用户A:用户名: test01密码: test01邮箱: test01@qq.com (这里换成你的真实邮箱)+ 用户B:用户名: test02密码: test02邮箱: test02@qq.com (这里换成你的真实邮箱)

• 然后我们通过找回密码处，尝试找回test01的密码：
  

• 这里我们可以尝试抓包看看：
  

• 我们尝试将email的值修改为test02的邮箱，发包：
  

• 然后我们就成功进入test02用户的重置密码界面：
  

• 这里能不能修改成功只用试一下就好了，这里就不继续演示了

• 这就是重定向用户，其实他的原理就是通过邮箱去绑定了用户，并且没有做验证码与当前邮箱绑定的判断，导致任何邮箱都可以利用当前的验证码绕过，造成漏洞

验证逻辑 - 修改响应包&跳过步骤URL

漏洞原理

• 修改响应包主要是因为网站采用的是前端验证的方式，我们可以通过拦截服务器的响应包，将其修改为正确的返回值，尝试绕过验证码验证
• 而URL跳过步骤则是我如果能够完整的抓到比如忘记密码步骤的包，那么可以尝试直接跳到最后一步绕过验证码
• 修改响应包是针对于验证在前端的
  1. 通过手机找回密码一般需要短信验证码验证，服务端需要告诉客户端，输入的验证码是否正确，如果客户端收到 true 的信息，那么就会向带着 true 的信息向服务端请求进入下一步，而服务端收到 true 的信息，就会允许客户端进入下一步，反之，如果是 false 的信息，服务端就不会允许客户端进入下一步。也就是说我们进入下一步的关键是让服务端收到客户端的 true 信息，而借助 burpsuite，我们可以修改服务端返回到客户端的信息，这样一来，我们就可以输入任意短信验证码，然后将服务端返回的 false 信息改为 true 就可以绕过短信验证码的验证了。
  2. 找回密码流程一般需要四个步骤：
     • 流程：验证用户名 - 验证短信验证码 - 输入新密码 - 重置成功
     • 这四个步骤应该紧紧相连，互相相关，只有通过了第一个步骤验证才可以进入下一个步骤，如果每个步骤之间没有进行关联性验证，就可能导致跳过关键验证步骤，从而导致重置任意账号密码。

• 实战中先每个流程正确的数据包以及响应包抓取下来，然后进行后续测试

案例演示

• 这里那个福利期货演示不了，没办法打开，只能说是看视频然后了解有这种测试思路即可
• 其实很简单，基本就是先测试一遍正确的流程，然后再对响应包进行修改，看能不能尝试绕过

实战SRC案例分享

• 这里同样来看看实战中的SRC漏洞的挖掘，学习一下测试思路

短信验证码回传显示

• 这里就是上面说过的，不再演示

修改用户对象重置任意用户

• 这里就是忘记密码的时候抓包，发现他有一个userid的参数，我们可以尝试修改该参数为他的前一位id
• 为什么是前一位呢，因为如果他是递增的id值，那么后面的id可能就没有被注册过，也就没什么用
• 然后这里修改之后发现能够成功重置其他用户的信息

修改响应包重置任意用户

• 还是一样到重置密码功能处，发送验证码然后抓包：
  

• 我们这里可以测试重定向，或者抓取服务器的响应包看看：
  

• 发现他的回显为false，并且提示验证码错误，那我们是不是可以猜测返回值为true或者success这些就说明验证码正确呢

• 于是修改响应包中的返回值为true，然后放包，发现他提示验证码正确，并成功进入重置密码页面：
  
  

未验证导致重置任意用户

• 这里就是开发者在验证的时候没有判断当前id和验证码信息是否绑定，导致攻击者可以通过修改参数r为其他的用户id，就能够重置其密码
  

总结

• 所以总的来说，其实就是看参数，然后修改再修改，看看开发者有没有存在逻辑上的纰漏