网络安全---渗透测试----业务逻辑漏洞（1-业务逻辑）

注意：由于业务逻辑漏洞本身的特殊性，很难用代码来具体解释（原因见下文📜），因此本文主要内容是业务逻辑漏洞的各种理论🤓，代码涉及极少，具体的实战演练会在后续更新哟⏩

注意：在挖掘业务逻辑漏洞时，对于一些可能会对目标业务造成影响的操作，一定要慎之又慎，比如验证越权修改账号密码时，应当只修改自己创建的账号，防止误修改其他人的账号信息！

三个问题讲清业务逻辑漏洞：

什么是业务逻辑？

1.业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。

2.业务逻辑是指在实际业务操作中，通过对业务规则和规程的分析和抽象，确定业务处理的规则和步骤。

业务逻辑通常由一组规则或者算法来描述业务流程，涉及到数据的处理、存储、分析和展示等方面，它是一个抽象的概念，在软件开发中占据着重要的地位。在面向对象编程中，业务逻辑通常被封装在对象的方法中，以此来实现对数据的操作和处理。在Web应用程序中，业务逻辑通常会包含在Controller层中，用于处理用户请求和响应结果。因此，业务逻辑是程序中最核心的部分，决定了整个程序的运行流程和结果。

业务逻辑本质上就是对真实业务的映射与抽象

“实际上，我们口口声声的业务逻辑，只是用代码实现的真实业务的规则映射。”

所有的逻辑都有漏洞吗？

不是所有的逻辑都有漏洞

逻辑漏洞：又称业务逻辑漏洞，是指由于程序逻辑不严谨或者逻辑太复杂，导致一些逻辑分支不能正常处理或者处理错误。

逻辑这种东西，无论它再基于客观事实的基础上，也一定是加了至少一点点主观推理的。如果是不加主观推理的东西，它就只是纯粹的客观事实，也不存在什么漏洞一说。但凡是加了主观推理的东西，都一定不是客观事实，哪怕有再少的主观推理，都必然有漏洞。

什么是业务逻辑漏洞？

业务逻辑漏洞是一类特殊的安全漏洞，业务逻辑漏洞属于设计漏洞而非实现漏洞，是业务逻辑设计不严谨导致的漏洞。

业务逻辑漏洞通常是由于无法预期可能发生的异常应用程序状态，因此无法安全处理它们所导致的。这些缺陷通常对那些没有明确寻找它们的人来说是不可见的，因为它们通常不会在应用程序的正常使用中暴露出来。但是，攻击者可以通过开发人员从未想过的方式与应用程序进行交互来利用这些漏洞。常见的业务逻辑漏洞如：参数篡改、重放攻击、流程漏洞等。

业务逻辑漏洞的成因：

应用程序在设计和实施的时候存在缺陷,攻击者可以故意诱发意外行为,就像是设计的方案 被人钻了空子。 通俗理解就是:在编写程序时,只考虑了常规的操作流程,即“当在A情况 下，就会出现B，此时执行C即可”，但是开发者却没有考虑当用户执行了意料之外的X 时会发生什么。这种对于异常情况的欠考虑，最终导致了业务逻辑漏洞的产生。

比如，luoyifang在登陆自己的账号并更改账号密码时，对发出的请求包进行修改，将用户名luoyifang改成了其他人的，如果后台应用程序没有充分考虑到这种情况，可能就会导致luoyifang在没有授权的情况下更改了他人的账号密码！

业务逻辑漏洞的核心就是绕过真实用户身份或正常业务流程达到预期的目的！

逻辑漏洞的特殊性与重要性：

常见的OWASP漏洞，比如一方之前一直在讲的SQL注入漏洞，或多或少都具有某些识别特征，都是可以被诸如SQLmap这样的漏洞扫描工具给自动或半自动化地扫描出来的，但是这样的工具却很难准确捕捉业务逻辑漏洞----这是因为业务逻辑漏洞本质上属于设计漏洞，是结构上的而不是实现上的，每一个业务逻辑漏洞都有它的独特性，很难复制或通过脚本捕获，因此逻辑漏洞大多需要配合代码审计和手工测试才能被发现---逻辑漏洞是工具无法替代手工的一类漏洞。

以逻辑漏洞中的支付漏洞为例，本质上，所有涉及购买支付方面的功能点处就有可能存在支付漏洞。用户=》商品、平台=》商家、用户=》商家 这三个因素在支付流程中都有可能存在支付漏洞而借助支付漏洞，攻击者可以任意修改交易金额，这会对企业/组织的财产安全造成巨大损失，危害极大-----对于支付漏洞，一方在这里拓展一下它的预防思路---既是预防思路，也是大家在挖掘支付漏洞时的思路：

对支付流程的每个环节进行严格校验，明确各个环节之间的依赖关系，防止跳过某一个环节。

用户确认购买后，多种手段相结合，第一时间验证商品价格（商品单价、商品数量、折扣优惠）、订单价格和到帐金额，并且这些数据不能放在一个请求包内，应当拆分并加密传输

对活动中使用的优惠券、折扣券的使用方式和发放数量进行严格把控，并预先进行测试

对敏感信息进行加密处理，例如身份 id、账号密码、订单号、金额等。 其次，建议在服务器端对其信息进行二次校验，避免修改乱序等情况。

如何寻找业务逻辑漏洞？

首要的一点是要熟悉目标的业务流程：

比如电信营业网厅的大致业务流程如图：

 再比如现在绝大部分网购的基本流程如下：

1、选择购物平台

2、注册账户(开通会员、修改密码)

3、搜索商品

4、购买商品

5、确认收货

6、给卖家评分

再再比如普遍存在的密码修改功能，简单来说，是不是要知道原密码才能修改新密码，或者说如果忘记密码，是否有对应的验证手机号并获取验证码的方式，如果没有原密码（就是在不知道原密码的情况下）但是通过我们的某些方式绕过了，那是不是就是一个逻辑漏洞？存在任意密码修改这一漏洞？

业务逻辑漏洞挖掘关键点：

验证码突破		身份认证安全
业务授权安全		业务一致性安全
业务流程乱序	业务逻辑漏洞挖掘关键点	业务数据篡改
业务接口调用		用户输入合规性
时效绕过测试		密码找回漏洞

下面对上述关键点的常见内容进行详解：

业务授权安全：

1.未授权访问 

业务逻辑漏洞中的未授权访问漏洞（Un authorized access vulnerability）是指攻击者通过利用系统或应用程序中的漏洞，未经授权地访问敏感数据或资源。这种漏洞通常涉及绕过身份验证机制、权限提升或会话劫持等技术手段。

通俗的来讲，未授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。

案例：

本来想放截图的，结果发现对方还没有修复😥，这里先讲一下思路：

可以尝试在登录某网站前台或后台之后，将相关的页面链接复制于其他浏览器或其他电脑上进行访问，看是否能直接访问成功----这里的其他浏览器或其他电脑应该是从来没有登陆过的（即没有储存相关cookie）!----同时也可以发现，这种方式是不会被WAF拦截的，因为这里的请求内容是“正常”的，这也是业务逻辑漏洞的重要特性

2.越权访问

越权访问漏洞的分类主要有水平越权和垂直越权：

a) 水平越权:相同权限的不同用户可以互相访问

b) 垂直越权:使用权限低的用户可以访问权限较高的用户

越权访问漏洞的产生原因可能包括：

1. 身份验证机制不完善：系统或应用程序的身份验证机制可能存在漏洞，使得攻击者可以伪造用户身份或绕过身份验证过程。
2. 权限提升：系统或应用程序的权限管理可能存在漏洞，使得攻击者可以提升自己的权限，从而执行敏感操作。
3. 会话劫持：系统或应用程序的会话管理可能存在漏洞，使得攻击者可以劫持其他用户的会话，从而进行越权访问。

通常情况下，一个 Web 程序功能流程是登录 - 提交请求 - 验证权限 - 数据库查询 - 返回结果。 如果“验证权限”这一步不够完善，便会导致越权。常见的程序都会认为通过登录后即可验证用户的身份，从而不会做下一步验证，最后导致越权：

越权漏洞的成因主要是因为开发人员在对数据进行“增、删、改、查”时 对客户端请求的数据过分相信而遗漏了权限的判定。

挖掘思路：

最基础的一种挖掘方式是，首先是通过定位鉴权参数（例如用户ID，订单号等），然后替换为其他账户鉴权参数的方法来发现越权漏洞。

只要涉及到编号，就可以尝试越权！

水平越权：比如说某一页面服务器端响应（不局限于 页面返回的信息，有时信息在响应包中，页面不一定能看见）中返回登录名、登录密码、手机号、 身份证等敏感信息，那么就可以试着修改这些参数，如果存在水平越权，通过对用户ID的遍历，就可以查看所有用户的敏感信息， 这也是一种变相的脱库，而且很难被防火墙发现，因为这和正常的访问请求没有什么区别，也不会 包含特殊字符，具有十足的隐秘性

垂直越权：对于可以创建普通用户的功能点，可以先创建一个或两个普通账户，再用普通账户去访问其他内容，如果存在垂直越权，通过修改访问的路径（一般这样的路径可以在网页源代码中寻找），就可以得到更高权限用户才能访问的信息。

注意，在进行有关账号信息的操作时，最好创建两个以上普通用户，修改时只修改自己创建的账号，防止影响到其他人的账号信息！

业务流程乱序：

1.顺序执行缺陷： 

假如某个网站的业务逻辑是先A过程后B过程然后C过程最后D过程

如果用户控制着他们给应用程序发送的每一个请求，并且能够按照任何顺序进行访问。于是， 用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站需要权限的位置了。

比如网站有一个充值的功能，在拦截包的过程中发现充值成功后会有一个充值成功的链接是 xxx.com/index.php?controller=site&action=payok&out_trade_no=aaaa，其中 aaa 是充值订单号。接下来注册一个新账号进行充值，在产生订单后复制其订单号然后取消支付，再把订单号贴到充值成功后的连接中，如果这时充值成功，则存在乱序问题。

业务接口调用：

1.重放攻击：

1.1 恶意注册----借助BurpSuite的重放模块，同时构造大量注册账户的情求

1.2 短信炸弹---在测试的过程中，发现众多的系统仅在前端通过JS校验时间来控制短信发送按钮，                           但后台并未对发送短信做任何限制，导致可通过重放包的方式发送大量恶意短信

1.3 无限刷积分/投票---比如每天签到送5个积分，如果签到接口未做限制，可以无限重放签到接                                          口，就能实现无限刷积分。投票接口未做限制，或仅仅在前端JS做限制，                                         可无限重放投票接口，给指定用户刷票。

如果发送大量请求导致IP被封怎么办？

例如目前大部分投票系统都有做限制，比如同一个IP每天只能投三次票，可尝试用X-Forwarded-For:127.0.0.1来绕过IP限制

X-Forwarded-For是HTTP请求头字段，
用来识别通过HTTP代理或负载均衡方式连接到Web服务器的客户端最原始的IP地址。

X-Forwarded-For是Squid 缓存代理服务器的开发人员最早引入的HTTP头字段，
并由IETF在HTTP头字段标准化草案中正式提出。如果没有X-Forwarded-For或者另外一种相似的技术，
所有通过代理服务器的连接只会显示代理服务器的IP地址，而非连接发起的原始IP地址，
这样的代理服务器实际上充当了匿名服务提供者的角色，
如果连接的原始IP地址不可得，恶意访问的检测与预防的难度将大大增加。

2.内容编辑

通过抓取请求包，可以将某些由客户端控制的内容修改为我们想要发送的内容----比如篡改短信内容进行钓鱼。

时效绕过测试：

针对某些带有时间限制的业务，修改其时间限制范围，例如在某项时间限制范围内查询的业务，修改含有时间明文字段的请求并提交，查看能否绕过时间限制完成业务流程。例如通过更改查询手机网厅的受理记录的month范围，可以突破默认只能查询六个月的记录。

业务一致性安全：

业务一致性安全是指业务系统在处理业务时，要保证业务数据的一致性，以及业务操作的合规性和合法性。如果业务系统在处理业务时没有考虑到这些因素，就可能存在业务逻辑漏洞，导致数据不一致、操作错误等问题。

例如，一个电商网站在处理订单时，如果因为某些原因（如网络故障、系统故障等）导致订单处理失败，但系统没有做相应的处理，就可能导致数据不一致。另外，如果系统没有对用户的操作进行合法性验证，也可能会导致操作错误或数据被恶意篡改。

例如如果某个订单请求包含收集号，可以抓包修改手机号码参数为其他人号码，查看是否能查询其他人的业务。

再比如在某些积分兑换商城中，100个积分只能换编号为001的商品,1000个积分只能换编号为005的商品， 在100积分换商品的时候抓包把换商品的编号修改为005，就可以用低积分换取高积分商品。

业务数据篡改：

篡改商品数据（数量/最大值）：

抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交， 查看能否以修改后的数量完成业务流程。

很多商品限制用户购买数量时，服务器仅在页面通过js脚本限制， 未在服务器端校验用户提交的数量，这是我们可以通过抓包修改商品最大数限制， 将请求中的商品数量改为大于最大数限制的值， 查看能否以修改后的数量完成业务流程。