目录

前言

一、登录认证模块

暴力破解

登录绕过

会话固定漏洞

Session会话注销

Cookie仿冒

二、越权

三、数量金额修改

四、前端js限制绕过

五、请求重放

六、短信/邮箱验证码漏洞

短信重放

验证码校验绕过

验证码重用/手机号修改

验证码回显

短信/邮箱验证码暴力破解

七、图形验证码漏洞

失效的图形验证码

八、未授权访问

---

前言

一、登录认证模块

当在做渗透测试漏洞挖掘的时候（红队除外），拿到一个登录框，除了尝试传统的注入类漏洞，我们还可以考虑一下如下类型的漏洞

暴力破解

登录绕过

通过修改response值来进行绕过，原理和下面的 短信校验绕过 一样

会话固定漏洞

由于HTTP的无状态性，导致Web应用程序必须使用会话机制来识别用户。会话固定攻击（session fixation attack）是利用应用系统在服务器的会话ID固定不变机制，即cookie中的sessionid值在登录前和登录后是一样的。借助他人用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

传送门 ——> 会话固定漏洞

Session会话注销

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户注销或退出应用系统时，系统应将客户端Session 认证属性标识清空。 危害 ：如果未能清空 Session 认证会话，该认证会话将持续有效，此时攻击者获得该Session 认证会话会导致用户权限被盗取

传送门 ——> Session会话注销漏洞

Cookie仿冒

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在 Cookie中， 并发送至客户端存储。攻击者通过尝试修改Cookie中的身份标识，从而达到仿冒其他用户身份的目的，并拥有相关用户的所有权限。

传送门 ——> Cookie仿冒

二、越权

越权即越权查看被人的信息，又分为水平越权和垂直越权，但是两者的本质都是一样的，只是越权的身份权限不一样而已

• 水平越权：相同级别的用户，如test到test1
• 垂直越权：普通用户到管理员，如test到admin

越权的漏洞类型还是挺多的，比如越权查看别人信息，越权修改密码，通过id进行订单遍历等。但是本质都是一样的，都是因为数据包中存在某个参数值，而这个参数值又决定了某个用户的身份。所以我将这个值进行修改，就可以查看到别的用户的信息

分享如下真实案例中越权修改密码的案例：

对账号150xxx3295进行重置密码，我们发现数据包中存在这个手机号，猜想服务器会不会仅靠这个手机号字段就决定对哪个手机号进行密码修改了？

于是将手机号改为别的手机号，返回重置密码成功的提示，并且用该手机号与新密码成功进行了登录，存在越权密码修改

其他的越权都是类似，都是通过修改数据包中的某个值进行测试。

相关案例 ——> API接口遍历越权获取个人信息_北遇-CSDN博客

三、数量金额修改

电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是确保在用户客户端与服务、业务系统接口之间的数据传输的一致性，通常在订购类交易 流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交的业务数据而导致的商品金额或者商品数量修改漏洞。

商品数量、金额修改测试，通过抓包修改业务流程中的交易金额等字段，例如在支付页面抓取请求中商品的金额或者数量字段，修改成任意数额的金额或者数量并提交，查看能否以修改后的金额或者数量完成业务流程

本质上也都是修改字段值。

漏洞修复

商品信息，如金额、折扣等原始数据的校验应来自于服务器端，不应接受客户端传递 过来的值

四、前端js限制绕过

很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务器端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数据完成业务流程

如下，商品限制购买数量为 2 份，多了就不让你买

通过观察发现客户端在前端浏览器使用JavaScript做了购买限制，尝试绕过限制提交购买请求，可以先提交购买两个然后通过抓包修改数量字段，改为 100 个后成功提交

还有一些文件上传也仅仅是通过前端进行限制，我们只需要先上传符合的文件类型，再抓包修改为脚本类型就行。

漏洞修复

五、请求重放

假设我和店家商量好了，只要去洗脚的时候说 "天王盖地虎" 就安排168员的套餐。于是过几天我去洗脚的时候对着店员说：天王盖地虎。然后被安排了一个 168 元的套餐。此时被旁边的人听到了，他根本就不知道“天王盖地虎”是啥。于是他也对店员说：天王盖地虎。然后也被安排了一个168的套餐。这就是请求重放。

 2. 观察每次订购相同商品的请求是否存在不同的随机Token、可变参数等，若有则检查这些随机数的变化情况和失效情况，是否在当前订购流程中唯一有效

3. 将该请求数据发送到重放模块，并且重放该请求，观察服务器端是否做出正确响应，若订购再次生效，订单再次生成则表明服务器存在脆弱性。如下一次兑换多次生效

漏洞修复

对每次请求都加上时间戳+随机串，时间戳规定了每次请求在限定的时间范围内有效。随机串确保每次请求的唯一性。如果在规定的时间内，该随机串重复出现，则判断该为重放请求。

ps: https不能预防重放攻击

六、短信/邮箱验证码漏洞

验证码常被用于网站用户注册、账户安全登录以及忘记密码、确认下单等应用场景，特别是一些涉及到用户个人敏感行为时候，为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。 在实际应用中，有很多产品的短信/邮箱验证码接口存在诸多逻辑漏洞，针对手机短信验证码可能存在的问题，这里总结常见的逻辑漏洞如下，供大家参考，邮箱验证码的问题也和此类似。

短信重放

有些网站没有限制对验证码的发送次数，导致某个时间内可以发送大量短信请求，消耗短信费用或服务

1. 漏洞检测

在点击发送短信的时候，截取数据包发送到repeater模块，然后不断地放包，看是否提示限制了发送次数，是否接收到大量的短信验证码。

2. 漏洞危害

大量发送获取短信验证码的请求，消耗用户短信费用

3. 漏洞修复

限制单位时间内发送短信的数量，如一分钟内只能发送一次

4. 短信重放之空格或\n绕过

有时候我们进行短信重放测试的时候，多发了几次包就会显示短信发送次数超过了限制，这时我们就可以在尝试在手机号后面加上一个逗号或者\n看是否能否绕过限制

验证码校验绕过

通过修改服务器的响应包来绕过验证码的验证，这个漏洞经常存在于用户注册，用户密码重置和用户登录的地方。

客户端端根据服务端返回的值，来确定是否进行下一步操作。比如验证码发送成功返回state的值是success，失败是false，然后客户端根据state的值，来确定是否继续下一步的动作。这样，我们可以通过修改响应包，跳过验证码这一步，直接进入到下一步

案例