目录
前言
在Web安全中，关于逻辑漏洞范围有很多，但作者在网上看到关于逻辑漏洞的梳理文章却少的可怜，本篇文章就将市面上有关于逻辑漏洞进行一番总结。供大家学习！
越权漏洞
越权漏洞是Web应用程序中一种常见的安全漏洞。该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查(比如说修改数据包的值或者直接访问其他用户相应页面的链接），访问或者操作其他用户或者更高权限用户才能访问到的页面或数据。
越权分为水平越权和垂直越权：水平越权指的是攻击者越权访问到了一个和他拥有相同权限用户的资源，而垂直越权指的是一个低级别用户访问到了一个高级别用户的资源。
水平越权
通过更换某个ID之类的身份标识，从而使得A账号获取(修改，删除等)B账号的数据；一般越权漏洞容易出现在权限页面(需要登陆的页面)增，删，改，查的地方，当用户对权限页面内的信息进行这些操作时，后台需要对当前用户的权限进行校验，看其是否具备操作权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞；
实验
我们登陆到pikachu靶场，首先看一下提示：
这里一共有两个用户，首先我们登录第一个kobe用户，来测试越权到luck用户。抓包分析一下
将图中的username后面的参数替换为lucy，放包。
成功进行水平越权，登录到lucy用户。
垂直越权
使用低权限身份的账号，发送高权限账号才能有的请求，获得其高权限的操作。
实验
（1）我们首先用admin/123456，进行登陆，发现有添加用户的功能。
（2）我们添加用户zahngsan进行抓包，发现添加用户的数据格式如下图所示，并记录下admin账户的cookie。
（3）我们紧接着用pikachu账号进行登录，抓包将pikachu用户的cookie替换为admin用户的cookie，并添加用户test。
（4）放包，我们成功利用pikachu用户利用admin的cookie成功创建了test账户。
支付漏洞
支付漏洞在Web漏洞挖掘之中非常常见，无非要点也就在修改金额，支付过程，修改数量等
直接修改商品价格
在支付过程中，购买商品一般分为三个步骤：订购，确认信息，付款，那么这个修改价格具体时修改那一步时的价格？在我看来你可以在这三个步骤中随便一个步骤进行价格的修改，进行测试，如果前面两步有验证机制，那么你可在最后一步付款进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值，你可以尝试小数目或者负数，去测试。
实验
（1）先把1个2588旗舰套餐加入购物车
（2）去购物车页面结算 ，点击立即购买，抓包。
（3） 如图我们发现图中的num5这个参数比较可疑，将图中的num5=1改成num5=-3450。
（4） 放包，我们发现支付金额变了。
修改支付状态
（1）这个很好理解，就是假设A商品，我们进行了购买，进行抓包，我们看到某一个字段。
0：表示支付成功
1：表示支付失败
假设我们暂时还未支付，bp显示的是1，我们将1修改为0，然后放包，然后显示购买成功，实际上我们没有支付金钱。
（2）还有我们去购买A商品，是10元，B商品是1000元，我们先购买A商品，将A商品的数据包替换给B商品，那么我们就能通过10元购买10000元的商品。
修改商品的数量
支付中。假如1个馒头10元钱，那么10个馒头就是100元，那么-1个馒头呢？
实验
我们如上图所示，点击立即购买，然后进行抓包分析。
然后我们发现qty这个参数非常的可疑 ，我们修改这个参数，修改为10，然后进行放包。
然后金额就变成了60000了。如果我们把数量改为负数呢？那岂不是倒给我们钱了：）
另类支付
我们在支付的时候，常常会给你一些优惠卷，积分，满减等等，而这些值同样都是由操作的空间
（1）修改优惠卷
一般优惠卷进行消费往往出现在第二个步骤当中，确认购买信息，这个页面当中，你可以选择相关的优惠卷，我们直接修改优惠卷的金额，等于商品的价格，或者直接将其改为负数，最后进行支付，如果说没有对这个点加以验证，那么直接可以支付成功。
（2）修改优惠卷金额及业务逻辑问题
当你修改其优惠卷值为任意值或负数想要支付的时候，会显示支付失败，或者金额有误等一些提示，可能这个时候，你会选择放弃，但是当你点开个人中心的时候，点击订单详情，如果存在这个逻辑问题，那么此时在你刚刚修改优惠卷金额后点击下一步支付的时候，其实已经产生了订单，在订单的金额内，你可以看到支付金额为0，然后点击支付就可以支付成功。
这里给大家一个小技巧，如果有自带的钱包功能，那么你就可以利用这个自带的钱包功能去支付这个订单，而不要利用其他支付类型，就可以支付成功了。
（3）修改积分金额
有些网站的积分，比如你消费了多少，就可以拥有一定量的积分，这个积分可以在你付款的时候进行折扣，如果这个积分的金额没有做好校验，那么你在支付当中将积分减去的金额变成商品本身的价格，或者负数，是不是就可以产生零元购了。
（4）满减修改
我们在双十一的时候，很多会有满300减100，这种功能，我们能不能将金额修改为满101减100呢？
修改支付接口
一些网站支持多种支付的接口，微信，支付宝，还有第三方的支付工具，然后每一个接口的值不一样，如果逻辑设计不当，那我随便选择一个点击时进行抓包，然后修改为一个不存在的支付接口，如果接口的相关处理没有做到位，是不是会支付成功。
重复支付
淘宝，京东会有很多试用卡。一张卡可以试用一个商品，我们可以将这个试用的商品数据包多次重复提交，如果服务端没有进行严格的校验的话，就会产生很多这样的订单，这时候，我们将这个商品退掉，会怎么样？我们会不会退回很多试用卡。
最小支付和最大支付
（1）最小支付
很多测试人员在测试漏洞的时候，往往会将金额修改为0.01或者负数，但这样会很容易错失掉一些潜在的漏洞，比如一些网站有金币或者积分什么的支付的时候可以用这些来支付，100积分等于10元，这个问题如果你在充值的时候将金额修改为0.01或负数会显示支付失败，但是如果你修改金额为1元，那么支付就会成功，也就是说1可以购买任意积分了？
其实你在测试的时候，就会发现，1元对应10积分，如果你修改0.01，那么对应的积分就是null，所以会显示失败，而当你修改为1元支付接口时存在的，其后面积分数为其他金额的积分，然后跳转过去支付就会以1元购买到比它多得多的积分，也可以时任意积分。
（2）最大支付
一般在开发当中，商品的金额都会用int型来定义，最大值2147483647，我们尝试修改为2147483648，看看是否能造成整数的溢出，有可能支付状态异常，从而导致支付成功。
四舍五入导致支付漏洞
我们以充值为例，余额值一般保存到分为止，那么如果我充值了0.001元也就是1厘，一般开发会在前端判断我们的数字，或者将最后一位四舍五入，使用支付宝值直接报错，因为一般第三方只支持到分。
那我们如果充值0.019？由于支付宝只判断到分，所以导致只能支付0.01，而由于我们支付成功，前端会将9四舍五入，直接变成0.02，所以等于直接半价充值。
首单半价，无线重构
很多会员啊什么的，为了留住用户，都会有首月半价，或者免费等等活动，我们可以抓取这个数据包，进行多次支付，就可以一直优惠购买(百度云去年就有这个漏洞，可以6元一月超级会员)
越权支付
这个问题很早之前就有了，现在很少存在这类问题，在支付当中会出现当前用户的ID，比如ID=1，我们将ID改为2，如果没有加以验证，我们是不是用用户2的钱支付了用户1买商品的钱。
无线次试用
一些网站的一些商品，比如云系列产品支持试用，试用时期一般为7天或者30天，一个账户只能试用一次，试用期间不能试用，但如果这个试用接口没有做好分配，那么很容易产生漏洞，比如支付的时候它的URL后面的支付接口为3，那么此时就会调用购买支付接口，但是由于你本身这个产品就是试用的，其相应值绑定了这个试用的产品，那么金额肯定是0，那么最后点击支付，你就可以看到支付成功，试用成功，又重复的试用了一次，然后他们的使用时间会累加到一起，这就导致了可无限制购买任何产品了。
客户端回显
这种利用回显抓取数据包，在修改验证，我们尝试的时候，有的网站会在你填写手机号后，点击发送验证码，会对你的手机号和IP进行验证，看看是不是本地号码，有的会对传输的信息有加密，在调用短信平台发送信息时，没有判断验证码和手机号是否绑定，把验证码校验功能直接放到客户端进行(也就是返回数据包中)，从而导致验证码在Response响应中回显出来。客户端回显，就是当注册或者绑定的时候，用户向网站系统发送一条短信验证码的请求，cookie中会包含短信验证码并且回显在数据包中，如cookie=xxxxxx es_id=534324,我们这时候通过抓包工具可截取真实的验证码，在Response响应中看到es_id=567475，通过分析，真实得验证码为567475，我们这时候，将验证码修改为正确的验证码，提交上去，就会成功注册或者绑定。
Response状态值
Response状态值，就是在服务器发送某个密码重置的凭据之后，出现特定的响应值(ture，1，ok，success等等，例如响应头中的HTTP/1.1 200 ok)
对Response状态值修改后，如果存在校验不严(存在逻辑漏洞)，并且回显值得校验是在客户端进行，就能使相关操作成功被执行；
就像密码重置中的验证码问题，如果回显值得校验是发送到客户端进行，通过对校验值得使用规则进行分析后，抓包将Response状态值改为正确得，然后放包，从而达到重置密码得效果。
我们账号密码输入admin/admin，进行抓包，我们将包首先放到Repeater中看看结构
然后我们发现Response中有两个参数，“0”和“账号密码错误”，这里我们根据经验判断“0”是状态响应值，我们拦截响应包，我们将其修改为1。
如下图我们成功登录进来了 。
失效的图形验证码
在很多的注册、登录、密码修改等页面都需要用户输入图形验证码，目的是为了防止恶意攻击者进行爆破攻击。
但是，在很多网站，存在图形验证码功能失效的问题，也就是说当第一次输入正确的图形验证码提交后，我不刷新该页面，之后该验证码还有用。
那么，我们如何判断该页面的图形验证码功能是否失效呢？
我们先输入正确的图形验证码和信息后，点击提交。用burpsuite抓包，查看返回的数据。然后我们重放，查看服务器返回的数据。如果第二次重放，服务器返回的是验证码错误的话，那么说明就不存在绕过图形验证码的可能性了。如果返回的数据和第一次登陆成功时相同的数据，那么该验证码就存在绕过了。
手机验证码是否可被爆破
对于大多数网站的注册、登录页面，修改密码页面，往往会有用手机号验证码登录的情况。这时，我们就可以考虑是否可以爆破手机验证码？
网站注册、登录、修改密码页面的逻辑是这样子的。我们用手机号码进行操作，输入手机号，然后点击获取验证码，后端服务器将验证码发给我们的手机号，我们将手机收到的验证码填入，点击注册、登录或者修改密码，后端校验验证码是否正确，正确即可成功。那么，我们会想，这种情况下的验证码是否可被爆破呢？
对于手机验证码被爆破的前提是：该页面处没有图形验证码或者图形验证码失效！如下，该页面注册处没有图形验证码。
倘若后端没有对验证码输入错误次数进行限制的话，也就是说无论你验证码输错几次，后端都不会有任何动作，这种情况下理论是可以爆破的。 一般的手机验证码为6位，当然也有4位的。如果是6位的话，理论情况下就需要爆破100万次，如果是4位就是1万次了。还需要考虑一点的就是后端验证码的时效性，我们进行爆破这么多次，是需要一定时间的。如果该验证码的时效性是一分钟或者低于我们爆破时间的话，也是不能进行爆破的。
如下的截图，就是手机验证码可被爆破！
手机验证码批量重放(短信炸弹)
对于网站发送短信验证码这个功能处，我们会想，是否可以利用这个功能进行短信验证码批量重放，来制造短信炸弹呢？
如下截图就是手机验证码发送的接口，我们可以批量重放该数据包，看后端返回的数据
如下，就是网站后台对同一手机号60秒钟内只能发送一条短信，这样就不存在手机验证码批量重放漏洞了！
相反，如果回显状态都是ok的话，那我们是不是就可以无线重放这个包了，然后手机号是不是就会一直接受短信？
有些时候，虽然后端会对其进行验证，但是还是可以想办法进行绕过：
1. 删除Cookie值
2. 手机号后加空格或者\\n
对于手机验证码批量重放的前提是：后端对同一手机号在短时间内的发送短信条数无限制。
注册页面批量注册
对于如下这种网站注册页面，没有手机短信验证码，那么，我们可以考虑，是否可以批量注册呢？
对于批量注册的前提是：该页面处没有图形验证码或者图形验证码失效！如下，该页面注册处没有图形验证码。
如下注册页面虽然需要输入姓名和身份证号，但是并未对姓名和身份证号去做核对，输入任意的姓名和身份证号即可。
我们抓包，先用正确的信息注册，记住注册成功时服务器返回的数据
{"content":"/User","type":1,"data":null}
然后对手机号进行批量遍历，可以发现，可以批量注册成功，存在批量注册漏洞。
注册页面覆盖注册
对于注册页面覆盖注册是指原来用一个手机号已经注册了账号，但是由于漏洞，导致可以再利用该手机号进行注册，并且会将之前注册的记录覆盖！
当我们用已经注册了的账号准备再注册时，发现会提示该手机号码已经存在！
我们抓包，发现后端检测该手机号已经注册了的话，会返回 true。如果检测该手机号没注册的话，会返回false。
我们拦截服务器返回的数据包，修改为false，放包
可以看到，这个手机号现在可以注册了！
网站登录页面绕过
不同网站判断用户登录成功返回的数据都不一样！
如果网站判断登录成功，网站后端返回设置Cookie的数据这种是没办法绕过的！跳转页面通过Cookie对权限进行了检查，因为Cookie都是后端随机生成的，我们没办法伪造，所以也就绕过不了。
如果网站判断登录成功，网站后端返回的是JSON格式的数据，并且没有设置Cookie 的话，这种是有可能可以绕过的。
不可靠的前端校验
还是会有许多的网站他们没有严格进行身份校验，他们往往是通过依靠帐号密码登陆后发送后回传的JSON数据来判断用户身份是否正确，这就暴露出了很大的漏洞，这种漏洞利用起来就相当的容易，往往只需要一个安全界的神器 BURP 就可以完成身份验证的绕过，在登录的时候输入正确的账户以及随意的密码，将报文拦截下来，然后选择 burp 里面的拦截返回包的功能，捕捉返回的状态码。
如下，网站后端通过返回JSON格式的数据给前端，前端以此来判断用户是否登录成功！
我们查看前端判断登录处的JavaScript代码，发现如下。
于是我们可以伪造服务器返回的数据包进行绕过
最后成功以admin身份登录系统！
任意用户密码重置
几乎所有需要登录的网站都有一个忘记密码然后重置密码的功能，如果网站在密码重置功能处的代码不够严谨，将可能造成任意密码重置的逻辑漏洞。
- 验证码失效，导致攻击者可以通过爆破其他用户手机验证码来实现任意用户密码重置
- 验证码未绑定用户：也就是我们可以利用自己的手机号来进行成功验证手机验证码，然而在提交修改密码处提交其他人的手机号，来实现修改其他人的密码
- 修改接收验证码的手机或邮箱：当我们修改密码时，输入正确的用户名，点击发送验证码，抓包，发现数据包中有该用户名对应的手机或者邮箱，我们将其修改为自己的手机或邮箱来接收验证码。输入我们收到的验证码，即可实现对该用户的密码进行重置。(这里还存在一个信息泄露，即知道用户名就能知道该用户对于的手机或邮箱)
- 跳过验证步骤：网站对修改密码的步骤，没有做校验，导致可以直接输入最终修改密码的链接，直接跳转到该页面，然后输入新密码达到重置密码的目的。首先使用我们自己的账号走一次流程，获取每个步骤的页面链接，然后记录页面3对应的输入新密码的链接，重置他人用户时，获取验证码后，直接输入密码修改页面链接到新密码的界面，输入密码重置成功。
- cookie值的替换：重置密码走到最后一步的时候仅判断唯一的用户标识cookie，并没有判断该cookie有没有通过之前重置密码过程的验证，导致可替换cookie重置他人用户密码。重置自己用户密码到达最后阶段，抓到数据包，并在第一阶段重新获取其他用户cookie，替换cookie到我们抓取的数据包中，发包测试。