大家好，又见面了，我是你们的朋友全栈君。
目录
随着各类前后端框架的成熟和完善，传统的SQL注入、XSS等常规漏洞在Web系统里逐步减少，而攻击者更倾向于使用业务逻辑漏洞来进行突破。
业务逻辑漏洞，具有攻击特征少、自动化脆弱性工具无法扫出等特点，也为检测和软件的安全性保障带来了一定的难度。
业务逻辑漏洞简介：
所有Web应用程序各种功能都是通过代码逻辑实现。任何Web应用程序，都可能存在大量逻辑操作。这些逻辑就是一个复杂的攻击面，但是它却常常被忽略。
许多自动化的扫描工具或者代码审计工具，都只能扫出类似SQL注入、XSS等常规的漏洞，难以发现逻辑漏洞(攻击特征不明显)。
业务逻辑漏洞产生的核心原因：
编程时，只考虑了常规的操作流程（如在A情况下，就会出现B，此时执行C即可）没有考虑当用户执行了意料之外的X时会发生什么。这种对于异常情况的欠考虑，最终导致了安全漏洞的产生。
应用中的缺陷通常分为两种类型：
在不同的应用中有相同的特征：类似SQL注入、XSS之类的常规漏洞。这一类漏洞的产生，主要是因为应用程序依赖用户的输入来执行某些重要的功能，但是在用户输入了一些非法字符时，应用程序又未能对于这些输入进行充分的校验和预处理。
与应用程序/业务领域严格相关：是指的业务逻辑漏洞。它是由错误的应用程序逻辑造成的。业务逻辑缺陷允许攻击者通过绕过应用程序的业务规则来滥用应用程序。这些攻击被伪装成语法上有效的Web请求，这些请求带有恶意意图违反预期的应用程序逻辑。
随着ORM框架的普及，以及新一代前端框架如AngularJS、Vue等的流行，常规的SQL注入、XSS等漏洞在实际的业务系统中越来越趋于少见。而在攻防演练过程中，可以用于突破系统的漏洞往往集中于在业务逻辑实现层面的漏洞上。
逻辑漏洞主要产生的位置
1.登录处 2.业务办理处 3.验证码处 4.支付处 5.密码找回处
登录处存在的逻辑漏洞
1.可以暴力破解用户名或密码：
没有验证码机制，没有根据用户名限制失败次数，没有根据ip限制失败次数等等
通常思路：
直接拿密码字典爆破某一个用户名
拿固定的弱口令密码，去跑top xxx的用户名
如果只是用户名限制失败次数，可以使用思路2的方法
在存在返回提示用户名错误或者密码错误的情况下，可以分别爆用户名和密码
常见限制：
有时候会发现用户名或者密码是密文加密，这时可能是通过前端或者其他方式加密，对于简单的来说base64编码和md5的签名是很好识破的，在爆破的时候可以选择encode和hash
2.session没有清空：
登出后服务器端的session内容没有清除，因此客户端重新带回登出前的session，也能够达到重新登录
通常思路：
在登录退出后，拿退出前的session，重新访问需要登录的界面
业务办理处存在的逻辑漏洞
水平越权
通常说的越权一般是修改get或者post参数，导致的查看到他人的业务信息，一般看订单处，个人信息处等位置的参数
通常思路：
拿2个账号，修改账号1的get或post参数给账号2
篡改手机号
在需要手机号的短信验证处，抓包修改手机号，可能做到非本账号手机号获取能够编辑本账号的验证码
通常思路：
抓包，查看get或者post参数存在手机号的地方，进行修改
验证码处存在的逻辑漏洞
登录验证码未刷新
没有清空session中的验证码信息
通常思路：
1.抓包多次重放，看结果是否会返回验证码错误，如没有返回验证码错误则存在未刷新
2.观察检验的处理业务，如果验证码和用户名密码是分2次http请求校验，则也可以爆破用户名和验证码
手机或邮箱验证码可爆破
没有对应的手机号或邮箱，但如果验证码纯数字4,5位左右，没有次数校验，可以爆破
通常思路：
拿自己的手机号或邮箱先获取验证码查看验证码格式，之后多次提交错误的看是否有次数现在，没有就爆破
手机或邮箱验证码回显到客户端
在发送给手机或者邮箱验证码时，会在response包中有验证码，因此不需要手机和邮箱就可以获取验证码
通常思路：
发送验证码时抓包，看返回包
修改response包绕过判定
在输入错误的验证码时会返回false之类的字段，如果修改response中的false为true，会识别为验证通过
通常思路：
抓包，选择do intercept-> response to this request ,放包，抓到下一个包就是response的包，可以修改，重放
支付处存在的逻辑漏洞
修改商品编号
如果业务是通过商品编号来判断价格的话，可能存在只修改A商品编号为B商品编号，做到以A商品的价格购买B商品
通常思路：
先准备2个商品的编号，将其中一个改为另一个
条件竞争
通过条件竞争使余额达到负数，从而买多个商品
通常思路：
支付处，多线程请求付款确认，结果如果余额为负数，则存在该漏洞
金额修改
金额直接写在了post或者get请求中，对其进行修改达到修改了商品金额的效果
通常思路：
抓包修改金额的字段
商品数量修改
在购买时，如果一个商品为负数，那么它的价格则会是负数，如果购买多种商品，将其中一个设为负数，降低整体的价格
通常思路：
购物车里选取多个商品，修改其中一个商品的数量，在购买后查看最终的价格
通过前端限制限购商品
有些商品限购1个，但是判定是通过前端，因此可以抓包后修改数量
通常思路：
抓取限购数量内的包，抓取后修改个数，重放
充值中放弃订单未失效
在充值中选取大额充值订单，放弃订单，获得订单号，之后充值小额订单，拿到充值成功的界面，将订单号修改为放弃的大额订单，观察是否成功
通常思路：
看看充值的时候是否有订单号字段，如果有在成功界面修改为未支付的订单号，观察充值是否成功
密码找回处的逻辑漏洞
验证码处的逻辑漏洞在密码找回处存在一样适用
修改发送的验证的目标为攻击者的邮箱或手机
在找回密码处，如果字段带上用户名，校验的邮箱或者手机号，将邮箱或者手机号改为自己的，如果自己的能够收到验证码并重置密码，则该漏洞存在
通常思路：
抓包，注意找回密码流程中的邮箱号或者手机号字段，修改其为自己即可
session覆盖
已知A的手机号，不知B的手机号，找回A的密码，输入验证码后到了设置新密码设置界面。这时在同一浏览器下重开窗口找回B的密码，获取验证码，刷新A设置新密码的页面，如果此时修改的是B账号的密码，则存在漏洞
通常思路：
准备2个账号，测试步骤如上所述
在邮箱收到找回密码连接时，依然可以使用该思路
弱token爆破
有些时候通过找回密码的时候填邮箱，邮箱此时会收到一个带有token的链接，点击链接就能跳转到重置密码的页面，如果token是base64，时间戳，位数较低的随机数则可以爆破
通常思路：
正常找回流程获取重置密码的url，了解token的规则后，爆破其他邮箱的重置密码url
密码找回流程绕过
在找回密码处，一般会有三个步骤页面，页面1找回用户的填写，页面2找回时的手机号短信验证码填写，页面3填写新密码，如果填好页面1，直接访问页面3能够重设密码的话，则会存在该漏洞
通常思路：
在设置好找回用户后，直接访问重设密码的url页面
避免业务逻辑漏洞
OWASP在描述业务逻辑漏洞时指出它虽然不如OWASP TOP10中的漏洞那样常见，但也依旧在许多重要的业务系统中存在。然而业务逻辑漏洞属于无法自动扫描出的漏洞。
OWASP指出可以使用应用程序威胁建模过程来避免系统中出现业务逻辑漏洞。
在系统生命周期里引入威胁建模可以带来如下方面的好处：
1.进行安全设计
2.更充分的对资源进行调研；更合理的对于安全、开发以及其他任务排定优先级
3.将安全和开发结合到一起，更好的互相理解以及构建系统
4.确定威胁和兼容性的需求，并且评估它们的风险
5.定义和构建需求控制
6.平衡风险、控制和易用性
7.基于可接受的风险，确定哪块的控制是不需要的
8.文档化威胁和缓解措施
9.确保业务需求（或目标）在面对恶意参与者、事故或其他影响因素时得到充分保护
10.定义安全测试用例来验证安全方面的需求
重要的安全步骤如下：
1.每一个应用程序都需要使用事务数据流和访问控制矩阵来描述业务逻辑
2.在设计业务逻辑时，就将它设计为防止业务逻辑滥用的。使用过程验证和控制假设应用程序业务逻辑可能被滥用的一些情况。
3.使用应用程序威胁建模来识别业务逻辑中存在设计缺陷的地方。
4.对于OWASP/WASC/SANS-25-CWE中描述的业务逻辑漏洞进行测试
5.对于业务逻辑的滥用建立确定的测试用例
6.分析风险并应用对策来减轻业务逻辑攻击的可能性和影响
微软也提供了威胁建模工具以供下载：https://aka.ms/threatmodelingtool
微软威胁建模的五个关键步骤如下：
1.定义安全需求
2.创建应用程序简图
3.确定威胁
4.缓解威胁
5.校验威胁是否被缓解
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/132894.html原文链接：https://javaforall.net
