常见的业务逻辑漏洞-CSDN博客

本文链接：https://blog.csdn.net/qq_73611706/article/details/144148220

一、课程知识点

业务逻辑漏洞介绍
业务逻辑漏洞分类
常见业务逻辑漏洞分析
业务逻辑漏洞修复

二、技术目标

1、掌握业务逻辑漏洞基本原理

2、掌握业务逻辑漏洞测试与挖掘技巧

三、课程内容

1、业务逻辑漏洞

1.1 业务逻辑漏洞基本介绍

所有Web应用程序都是通过代码逻辑实现各种功能。即使一个简单的Web应用程序，都可能包含着数目庞大的逻辑操作。这些逻辑就是一个复杂的攻击面，但是它却常常被忽略。许多自动化的扫描工具或者代码审计工具，都只能扫出类似SQL注入、XSS等常规的漏洞，因为它们相比于业务逻辑漏洞而言具有更加显著的攻击特征。

业务逻辑漏洞产生的最核心原因，就是在编写程序时，只考虑了常规的操作流程，即“当在A情况下，就会出现B，此时执行C即可”，但是开发者却没有考虑当用户执行了意料之外的X时会发生什么。这种对于异常情况的欠考虑，最终导致了安全漏洞的产生。

1.2 业务逻辑漏洞分类

应用中的缺陷通常分为两种类型：

在不同的应用中有相同的特征
与应用程序/业务领域严格相关

其中第一种类型的缺陷，就是类似SQL注入、XSS之类的常规漏洞。这一类漏洞的产生，主要是因为应用程序依赖用户的输入来执行某些重要的功能，但是在用户输入了一些非法字符时，应用程序又未能对于这些输入进行充分的校验和预处理。

第二种类型的缺陷，则是指的业务逻辑漏洞。它是由错误的应用程序逻辑造成的。业务逻辑缺陷允许攻击者通过绕过应用程序的业务规则来滥用应用程序。这些攻击被伪装成语法上有效的Web请求，这些请求带有恶意意图来违反预期的应用程序逻辑。

随着ORM框架的普及，以及新一代前端框架如AngularJS、Vue等的流行，常规的SQL注入、XSS等漏洞在实际的业务系统中越来越趋于少见。而在攻防演练过程中，可以用于突破系统的漏洞往往集中于在业务逻辑实现层面的漏洞上。

2. 业务逻辑漏洞场景分类及挖掘思路

2.1 常见的业务逻辑漏洞分类如下：

绕过验证
越权访问
交易活动漏洞
其他漏洞

2.2 常见的业务漏洞挖掘思路：

3、业务逻辑漏洞分析

3.1绕过验证类漏洞分类

涉及身份和权限验证的功能都可能存在绕过验证的漏洞，常见的场景包括登录、二次验证、辅助验证等

3.1.1 客户端校验绕过

客户端校验是常见的一种校验方式，也就是在客户端校验用户的输入，将校验结果作为参数发送至服务端，或利用前端语言限制用户的非法输入和操作。面对此类的校验方法可以通过修改前端语言或者在传输中对参数进行篡改来绕过验证。

常见客户端验证方法：

1、使用HTML的input标签的属性限制用户输入的内容。

2、使用javascript对用户输入进行校验，当输入非法内容自动清除或禁止用户提交表单。

3、将用户数据在本地校验结果，作为请求参数或cookie提交。

4、将用户需要进行校验的关键数据（如：活动次数）作为请求参数或cookie提交。

常见测试方式：

1、使用浏览器的审查元素功能对HTML进行修改，解除HTML限制。

2、在请求目标页面过程中使用burp拦截服务器的返回包，修改HTML和javascript，修改或解除相关校验机制。

3、先输入正常的数据提交请求，burp拦截请求包，将数据修改为恶意数据后再提交。

4、在提交请求的过程中使用burp拦截请求包，将校验结果或关键数据修改为满足要求的数据再提交。

测试案例

某系统需要购买才能观看视频，不同的课程以ID划分。

通过测试发现是否付费只靠前端js控制，更改courseID就可以看到不同的课程，recordURL就是视频播放的链接，无需登录即可播放。

根据播放地址中的videoCode，可获取视频下载地址:

通过脚本，可将全站视频下载下来。

3.1.2 客户端验证信息泄露

程序员在编写验证程序时有可能会将验证信息直接泄露到客户端，攻击者可以通过分析服务端的返回数据直接获得关键的验证信息从而完成验证。

客户端验证信息泄露途径

1、直接将验证信息（验证码）返回到客户端页面的源码中。

2、将验证信息在接口中返回。

常见测试方式

1、通过BURP拦截请求及响应数据包，找到验证成功和验证失败时返回包中的关键字，将验证失败的关键字篡改为验证成功时的关键字后再返回客户端。

2、使用burp拦截请求及响应数据包，跟踪验证成功时触发的请求，尝试在验证失败的情况下直接构造相同的请求

测试案例

某免费wifi连接时需要使用发送到手机的密码进行验证，抓取发送密码的数据包时，发现密码返回客户端，导致任意全网账号可以登录联网

3.1.3 客户端流程控制

程序员在编写验证程序时有可能会验证结果返回到客户端，由客户端根据服务端提供的验证结果进行下一步操作，攻击者可以通过篡改验证结果或直接执行下一步操作实现绕过。

常见测试方式

1、通过BURP拦截请求及响应数据包，找到验证成功和验证失败时返回包中的关键字，将验证失败的关键字篡改为验证成功时的关键字后再返回客户端。

2、使用burp拦截请求及响应数据包，跟踪验证成功时触发的请求，尝试在验证失败的情况下直接构造相同的请求

测试案例

某系统重置密码需要三个步骤，首先要输入图片验证码。

然后需要通过短信验证码验证身份。

访问http://*.*.*.*/a/user/findPasswordSetp 直接跳到重置密码的页面。

绕过验证身份流程，成功修改密码密码。

3.1.4 操作目标篡改

如果某操作采用了连续身份校验机制或身份校验过程与操作过程分离，可以尝试在身份验证过程中替换身份校验对象或操作对象实现绕过验证。

常见测试方法

1、如果目标操作与身份校验功能分离，可以尝试在完成身份校验后修改操作目标。

测试案例

修改某系统的绑定手机。

选择免费接收短信校验码修改。

将修改的手机号改为自己的手机号码。

通过修改的手机号码收到的校验码修改手机号。

发现可以成功修改成新的手机号。

3.1.5 参数篡改

程序员在编写验证程序时有可能会对验证码字段进行正确性校验，但当验证码字段不存在或为空时就直接通过校验。

常见测试方法

通过BURP拦截请求数据包，将验证码字段值设置为空或删除后再提交请求。

测试案例

西部证券某系统存在绕过验证漏洞，可以通过删除验证码（securityCode字段）进行爆破。

使用burp suite抓取登录的数据包，发现含有验证码字段（securityCode）

删除验证码字段（securityCode）进行爆破。

爆破成功，并可以使用爆破出来的账号密码进行登录。

3.1.6 暴力破解

暴力破解是利用大量猜测和穷举的方式来尝试获取用户口令的攻击方式，如果身份验证模块设计的不好攻击者可以利用自动化攻击进行暴力破解，大大增加了密码被破解的风险。

常见测试方式

1、分别使用“有效的用户组合错误密码”和“不存在的用户”尝试进行身份验证操作，使用抓包工具跟踪验证流程，确认流程和返回信息是否一致，若两种情况下流程和返回信息完全一致，则认为无风险。

2、使用常见的默认账号和默认密码尝试进行登录，若登录成功则记录为中风险或高风险漏洞（若账号具备管理权限记录为高风险漏洞，账号具备普通权限记录为中风险漏洞）。若应用具备账户枚举漏洞或其他暴力破解漏洞，可利用相关漏洞使用自动化工具进行测试，否则使用手动测试。

测试案例

登录的时候发现没有任何的防护措施。

抓取登录的数据包，发现用户名密码明文传输。

使用burp suite的intruder的功能对j_loginid字段进行爆破

使用弱密码及常见用户名进行爆破，长度为495的，为爆破成功的。

使用用户名密码可成功进入系统。

3.2 越权访问类漏洞

3.2.1 水平越权

即用户A和用户B属于同一个权限组，水平越权就是用户A可以看到用户B才可以看到的一些内容。一个简单的例子，就是保单管理系统中，每个人都只可以看到自己的保单，如果出现用户A可以查看到用户B的保单的现象，此时就发生了水平越权。

水平越权通常发生在对数据的增删改查等操作中，当一个请求中包含了请求对象标识，可以尝试将该对象标识该为其他请求对象的标识，如果能够成功访问，可以认为存在水平越权漏洞，以下列举了常见可能发生水平越权漏洞的场景和测试方法。

常见水平越权漏洞场景

1、在访问请求中包含了用户ID或其他可以唯一标识用户身份且可猜测的参数（如userid、用户名、邮箱、手机号、身份证或其他证件号等），且仅根据该参数决定可以访问的数据。

2、在访问请求中包含了可猜测的资源对象ID如（订单号、服务号、受理号、记录号等，可猜测指ID的变化部分为10位以内字符组成或可以通过其他易于获取信息推理得到。），且仅根据该参数决定可以访问的数据。

3、在访问请求中包含了可猜测的文件名（可猜测指ID的变化部分为10位以内字符组成或可以通过其他易于获取信息推理得到），且仅根据该参数决定可以访问的数据。

常见水平越权漏洞测试

1、使用两个账号分别登录后访问相同的功能模块，记录正确的请求对象标识，使用burp拦截其中一个用户的请求，将其中的请求对象标识替换为另一个用户的请求对象标识，如果能够成功访问，则认为存在水平越权漏洞。

2、分析请求对象标识的生成规律，采用burp或自动化脚本批量遍历请求对象标识，如果能够成功访问其他用户的数据，则认为存在水平越权漏洞。

测试案例

某航空公司存在水平越权漏洞，提交订单后抓取数据包。

可以发现请求中有蛮多ID信息，通常情况下，我们一般会挨个测试，是否存在越权漏洞，其中passenger1d1是乘机人，contactId联系人。

经测试可发现这两个参数修改后，可查看到其他乘机人的身份证及联系人信息

3.2.2 垂直越权

即用户A和用户B属于不同的权限组，如用户A属于普通用户权限组，而用户B属于管理员权限组，垂直越权就是用户A可以看到用户B才可以看到的内容。一个简单的例子，用户A可以看到通讯录界面，用户B可以看到通讯录和用户管理的界面（其中用户管理界面可以看到用户密码）。如果用户A修改一下请求的URL即可以看到作为管理员才可已看到的全部用户密码，此时就发生了垂直越权。

垂直越权漏洞通常可以理解为功能级访问控制缺失，即某个用户没有在没有访问某个功能的权限的情况下可以成功的访问该功能。以下列举了常见垂直越权漏洞的场景和测试方法。

常见垂直越权漏洞场景

1、用户在未登录的情况下可以访问某些需要登录才能访问的功能模块，包括WEB页面和API接口。

2、一个低权限用户可以访问高权限用户才能访问的功能模块，包括WEB页面和API接口。

常见垂直越权漏洞测试

1、选择一些重要的WEB页面或API请求，通过burp记录请求包格式，并在没有登录的情况下尝试沟通相同的请求，如果能够成功请求，则认为存在垂直越权漏洞。

2、选择一些只有高权限账户才能访问的重要的WEB页面或API请求，通过burp记录请求包格式，并在只使用了低权限账户登录的情况下尝试沟通相同的请求，如果能够成功请求，则认为存在垂直越权漏洞。

测试案例

腾讯企业邮箱没有在服务端做用户权限限制导致低级权限用户可访问高级权限用户才能访问的功能模块，新建一个低权限用户，仅允许管理内部公告，并使用新建的用户登录

直接修改URL访问用户组织架构管理（高权限用户才能访问的页面）

执行高权限用户才能做的创建账号功能

添加成功

3.2.3 不安全的权限控制框架

权限控制框架决定了业务系统如何进行权限控制，若系统采用了不安全的权限控制框架，则会面临全局的权限控制失效。在测试过程中如果发现一个系统存在大量的越权访问漏洞，很有可能是权限控制框架出现了问题，此时应建议开发者重新调整权限控制框架，而不是简单的修复各个漏洞。

常见垂直越权漏洞场景

1、在用户成功登陆后给用户分配一个简单的用户ID存储在cookie 中（与用户名相同、较短的纯数字、或由字母+递增的纯数字），后续所有权限控制都基于用户ID来判断用户身份。

2、在用户成功登陆后给用户分配一个简单的用户ID（与用户名相同、较短的纯数字、或由字母+递增的纯数字），后续所有的表单都会包含一个值为用户ID的隐藏字段随所有的请求一起提交，权限控制都基于用户ID来判断用户身份。

3、采用javascript进行权限控制，即当用户访问没有权限的页面时服务端自动在页面上添加javascript代码跳转至其他页面。（目前已较为少见）

4、将用户权限等级标识直接存储在cookie中，在请求时直接通过cookie中的权限等级判断用户权限。

常见垂直越权漏洞测试

1、获取两个用户ID，使用其中一个用户ID登录系统，在提交请求时将用户ID篡改为另一个用户的用户ID，如果能够访问到另一个用户的数据，可以认为权限框架存在漏洞。

2、使用burp拦截请求和响应数据包，如果发现用户在访问没有权限的页面时被加入了javascript跳转代码，通过burp删除相关代码后再返回给客户端，如果能成功访问相关页面，可以认为权限框架存在漏洞。

3、使用低权限用户登录，并将cookie中的权限标识修改为高权限用户的权限标识，尝试访问高权限用户才能访问的页面，如果访问成功，可以认为权限框架存在漏洞。

测试案例

58同城某重要业务平台权限控制以及设计缺陷，可通过修改POST参数来获得管理员权限。

首先，使用一个具有管理员权限的账号A登陆，查看管理员权限。

其次，使用只有普通用户权限的账号B登陆

最后，使用普通权限账号B再次登陆，在登陆过程中修改POST请求包中ad_userId参数，即可获得管理员权限。

3.3 交易活动类漏洞

交易活动类功能是WEB应用常见的功能之一，涉及使用资金、虚拟货币、积分等进行交易或参与活动类赢取奖励的功能，这些功能在设计实现时如果没有进行充分的安全性考虑，就会产生业务逻辑漏洞。

交易活动类功能绕过出现业务逻辑漏洞，可能直接影响用户或平台的资金安全，给用户或平台造成较大的业务损失。

3.3.1 重放攻击

攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的。这种攻击会不断恶意或欺诈性地重复一个有效的数据传输。

常见测试方式

1、使用Burp对业务已处理的请求包进行两次或多次请求，进行原始回执包和重放回执包比较，两者一样说明重放成功。

测试案例

某平台的抽奖活动，测试在赠送50M流量，提示一个用户只能赠送一次。

获取到赠送的请求包时，再次发送，赠送成功。可无数次发送赠送流量的请求包来获取流量，故存在重放攻击。

3.3.2 数据篡改

测试能否通过参数篡改的方式修改交易金额，实现非法获利，除了买卖以外，转账、打赏、红包、兑换等各类涉及资金、虚拟币、积分等功能的实现过程也需要进行本项测试。

常见测试方式

1、在买卖、兑换等交易过程使用抓包工具抓包跟踪交易流程，查看是否有涉及商品单价、订单总价等金额的参数，如果有则尝试将相关参数改为较小的金额、0或者负数，如果可以按照修改的金额交易成功实现非法获利，则记录高风险漏洞。

2、在买卖、兑换等交易过程使用抓包工具抓包跟踪交易流程，查看是否有涉及商品数量的参数，如果有则尝试将相关参数改为0或负数，如果可以引发程序逻辑错误导致非法获利，则记录高风险漏洞。

3、在转账、打赏、红包等交易过程使用抓包工具抓包跟踪，查看是否有涉及金额（或虚拟币、积分数量）的参数，如果有则尝试将相关参数修改为负数，如果可以引发程序逻辑错误导致非法获利，则记录高风险漏洞。

测试案例

中国国旅存在支付逻辑漏洞导致一元买任意张数旅游票。

中国国旅买票的时候可以通过burp抓包，直接将金额修改成1元。

并且订单提交成功，支付金额为1元，故存在漏洞。

3.3.3 业务流程绕过

客户端测试活动业务是否存在漏洞，能否在未满足活动参与条件的情况下参与活动或获得收益常见的客户端验证方法

常见测试方法

1、对于参与次数有限制的活动，采用绕过验证的方法，测试是否能够绕过限制重复参与活动，绕过成功则记录高风险漏洞。

2、对于参与时间有限制的活动，采用绕过验证的方法，测试是否能够绕过限制提前参与活动或在活动结束后参与活动，绕过成功则记录高风险漏洞。

3、除上述测试方法外，采用绕过验证的方法，测试是否能够在未满足活动参与条件的情况下参与活动或获得收益，绕过成功则记录高风险漏洞。

4、对于活动类功能，查看活动参与过程是否具备防止批量化自动操作的人机识别手段（如短信验证码、图片验证码、语音识别、重力识别等），若无任何相关手段或相关手段可绕过，则记录存在中风险漏洞。

测试案例

北京电信推出的流量红包功能，结果激活码就9位数字，爆破了一下后4位数字就领了1G的流量，用了不到1分钟的时间。

3.4 其他漏洞原理与挖掘

常见消息推送接口主要包括短信接口、邮件接口等向手机或邮箱发送消息推送的API接口，如果这些接口没有采取一些有效措施防止攻击者恶意调用，可以认为存在安全漏洞。

攻击者常见的恶意调用方式包括资源滥用和信息篡改者：

资源滥用如短信炸弹、邮件炸弹等，使用自动化工具频繁调用接口，消耗系统资源，对用户进行骚扰。

3.4.1 资源滥用

主要针对消息推送接口（短信接口、邮件接口等向手机或邮箱发送消息推送的API接口），测试这些接口能否被滥用或发送恶意消息。

常见测试方法

1、使用抓包工具跟踪消息推送接口的调用过程，如果满足以下要求（如业务或行业有相关规范要求以相关规范要求为准），则认为不存在本漏洞，如果仅满足部分要求、可以无限制使用自动化工具重复调用或限制措施可以通过绕过验证的方式绕过，则记录中风险漏洞：

·接口调用有时间间隔限制且不小于一分钟

·接口调用有单位时间内调用次数限制，如每小时最多调用多少次或每天最多调用多少次。

2、使用抓包工具跟踪消息推送接口的调用过程，如果可以通过参数篡改等方式修改消息推送接口的推送的内容，则记录高风险漏洞。

测试案例

在打开登录页面，点击获取验证码：

同时利用工具抓取数据包，并发包查看，问题参数receivePhone

遍历手机号后三位，成功发送:

4、业务逻辑漏洞修复

4.1威胁建模

威胁建模是通过识别目标和漏洞来优化系统安全，然后定义防范或减轻系统威胁的对策的过程。

威胁建模是分析应用程序安全性的一种方法。这是一种结构化的方法，使您能够识别，量化和解决与应用程序相关的安全风险。威胁建模不是代码审查方法，但却是对安全代码审查过程的补充。在 SDLC 中包含威胁建模可以帮助确保从一开始就以内置的安全性开发应用程序。这与作为威胁建模过程一部分的文档相结合，可以使审阅者更好地理解系统。这使得审阅者可以看到应用程序的入口点以及每个入口点的相关威胁。威胁建模的概念并不新鲜，但近年来有了明显的思维转变。现代威胁建模从潜在的攻击者的角度来看待系统，而不是防御者的观点。微软在过去的几年里一直是这个过程的强有力的倡导者。他们已经将威胁建模作为其SDLC的核心组件，他们声称这是近年来产品安全性提高的原因之一。

当在SDLC之外执行源代码分析时（例如在现有的应用程序上），威胁建模的结果通过推广深度优先方法与宽度优先方法来帮助降低源代码分析的复杂性。您可以不用同等重点地审查所有源代码，而是将安全代码评估放在优先级上，这些组件的威胁建模已经排在高风险威胁之下。

威胁建模可以在软件设计和在线运行时进行，按照“需求-设计-开发-测试-部署-运行-结束”的软件开发生命周期，威胁建模在新系统/新功能开发的设计阶段，增加安全需求说明，通过威胁建模满足软件安全设计工作；如果系统已经在上线运行，可以通过威胁建模发现新的风险，作为渗透测试的辅助工作，尽可能的发现所有的漏洞。

在系统生命周期里引入威胁建模可以带来如下方面的好处：

·进行安全设计

·更充分的对资源进行调研；更合理的对于安全、开发以及其他任务排定优先级

·将安全和开发结合到一起，更好的互相理解以及构建系统

·确定威胁和兼容性的需求，并且评估它们的风险

·定义和构建需求控制

·平衡风险、控制和易用性

·基于可接受的风险，确定哪块的控制是不需要的

·文档化威胁和缓解措施

·确保业务需求（或目标）在面对恶意参与者、事故或其他影响因素时得到充分保护

·定义安全测试用例来验证安全方面的需求

建设过程关键重要步骤：