以体系分类，业务流程很广，所以分类也大； 第二个和第三个以功能点和功能类分别， ！API调用！
撸羊毛如果利用了业务逻辑漏洞则构成
漏洞分类
业务逻辑漏洞存在的场景主要有：
用户注册场景
登录场景
支付场景
修改资料场景
信息交互场景
绑定手机场景等
权限控制
两种越权的比较：
平行越权访问漏洞，指的是权限平级的两个用户之间的越权访问。
垂直越权访问漏洞，指的是权限不等的两个用户之间的越权访问。
平行越权
什么是平行越权？
一个正常的用户a通常只能对自己的信息进行修改，但由于系统为对信息修改进行一个判断，判断当前操作是否属于对应的用户的操作，导致用户a可以操作其他人的信息。
注册两个相同账户，修改用户标识符看能否平行越权
平行越权漏洞的防护
增加访问与操作对象的用户属性，在对目标对象进行访问与操作时，服务端校验会话与对象的用户属性，在校验通过后才能执行读取和操作。
垂直越权
什么是垂直越权？
在博客论坛中，一个正常的普通用户a，通过burpsuite抓包修改自己的用户ID为管理员的用户ID，使其成功登录了管理员的帐号。
需要获取不同权限用户的标识地址
垂直越权漏洞的防护
所有访问采取默认拒绝机制，采取基于角色访问控制，对于各个功能的访问，规定不同角色拥有不同的访问权限，当用户在使用该功能时，系统要校对用户的权限和访问控制机制是否与规定相同，通过校对者才能使用，否则拒绝使用该功能。
接口控制
什么是接口控制？
在博客论坛中，一个正常的普通用户a使用官方提供的API接口构造链接，用户b通过点击该链接后进行发送或转发用户a指定的内容。
接口类漏洞大多数都是因为接口没有做验证或者其他预防机制，导致被攻击者所利用，比如一些下载链接接口导致未授权下载，登录接口无验证导致撞库等等。
越权漏洞修复建议
基础安全架构，完善用户权限体系。要知道哪些数据对于哪些用户，哪些数据不应该由哪些用户操作
鉴权，服务端对请求的数据和当前用户身份做校验
不要直接使用对象的实名或关键字
对于可控参数进行严格的检查与过滤
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
密码找回类 ：可以先进行正常测试流程，然后找到测试点
凭证破解
凭证爆破出现此情况突破办法
第一步验证是否过于频繁未进行数字提纯，添加空格等特殊字符绕过验证进行下一步提纯验证验证码
弱token
一般都是找回密码链接处对用户标识比较明显，弱token能够轻易伪造和修改。
邮箱收到修改密码邮件参数带有时间戳
前端校验
在前端进行验证，相当于没有进行任何防范措施，比如登陆状态如果只以登陆状态码进行判断登陆成功标识，那么修改登陆状态码就能进行登录。、
步骤可跳过
通过跳过某些关键步骤来达到修改别人密码的目的
逻辑漏洞小结
测试业务的时候，先了解清楚业务整体流程，可以利用思维导图快速理清各个业务之间的关系，也可以通过查看 JS 了解（JS 中可能会存在信息泄漏）
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
支付逻辑漏洞
支付漏洞主要涉及四个方面
支付过程中可以直接修改数据包中的支付金额
没有对购买数量进行负数限制
请求重放
参数干扰
支付金额
这种漏洞应该是支付漏洞中最常见的。开发人员往往会为了方便，直接在支付的关键步骤数据包中直接传递需要支付的金额。而这种金额后端没有做校验，传递过程中也没有做签名，导致可以随意篡改金额提交，只需要抓包看到有金额的参数修改成任意即可。
支付数量
这中案例也比较常见，产生的原因是开发人员没有对购买的数量参数进行严格的限制。这种同样是数量的参数没有做签名，导致可随意修改，经典的修改方式就是改成负数。
当购买的数量是一个负数时，总额的算法依然是“购买数量×单价=总价”。所以这样就会导致有一个负数的支付金额。若支付成功，则可能导致购买到了一个负数数量的产品，也有可能返还相应的价钱到你的帐户上。
并发逻辑漏洞
并发漏洞主要是测试服务器是否会响应多次的请求。
比如，一个签到积分活动，我们拦截下签到的请求包，复制该请求n个，然后全选一并发送，查看响应结果，如果全部为200ok，观察积分是否多出很多，以此来检测是否存在并发逻辑漏洞。
优惠券逻辑漏洞
通过遍历获取大量优惠券，在前端页面更改参数导致查询结果出错，生成新的优惠券。
回顾总结
让事物以迥异于初衷的方式运作 参考链接https://www.freebuf.com/news/195837.html