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

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

Session会话注销

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

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

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

传送门 ——> Cookie仿冒

二、越权

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

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

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

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

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

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

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

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

三、数量金额修改

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

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

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

漏洞修复

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

四、前端js限制绕过

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

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

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

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

漏洞修复

商品信息，如金额、折扣、数量等原始数据的校验应来自于服务器端，不应该完全相信客户端传递过来的值。类似的跨平台支付业务，涉及平台之间接口调用，一定要做好对重要数据，如金额、商品数量等的完整性校验，确保业务重要数据在平台间传输的一致

五、请求重放

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

请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“ 一次购买多次收货 ” 等违背正常业务逻辑的结果。

漏洞检测

该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题，通过该项测试可以验证交易流程中随机数、时间戳等生成机制是否正常

1.点击提交订单时抓取订购请求

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

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

漏洞修复

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

ps: https不能预防重放攻击

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

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

短信重放

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

1. 漏洞检测

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

2. 漏洞危害

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

3. 漏洞修复

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

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

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

验证码校验绕过

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

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

案例

以某 P2P 网站系统注册功能为例。首先输入任意手机号码和密码，我们此处以 18888888886 为例，单击 “ 获取手机验证码” ，由于我们无法获取到 18888888886 这个手机的真实验证码，我们随意填写一个验证码1234

单击注册领红包并通过 burp 对数据包进行截获，右击选择 Do intercept—Response to this request

然后单击 Forword 后， burp 工具里显示的就是网站返回的数据包，此时被拦截了。因为我们填写的手机验证码1234 肯定是错误的，而此时 res_code 的值为 1 ，证明了当手机验证码错误时res_code 的值为 1 。我们将返回数据包中的 res_code 的值改为 0 ，从而实现绕过验证码