助你一臂之力
📋问题1：挖掘逻辑需要注意什么？
🎯上下文逻辑的顺序，尝试颠覆
🎯拥有账号、付费服务等找到更多测试点
🎯猜测开发人员的防御机制
🎯寻找加密算法
🎯多保留数据包，已备复盘与再次重放
一、业务逻辑漏洞
1、意义
1、危害：业务逻辑漏洞是应用程序设计和实现中的缺陷，允许攻击者引发意外行为。这可能使攻击者能够操纵合法功能以达到恶意目的。这些缺陷通常是由于未能预料到可能发生的异常应用程序状态，因此未能安全地处理它们。
2、寻找：逻辑缺陷对于那些没有明确寻找它们的人来说通常是看不见的，因为它们通常不会在应用程序的正常使用中暴露出来。但是，攻击者可能能够通过以开发人员意想不到的方式与应用程序交互来利用行为怪癖
3、作用：业务逻辑的主要用途之一是强制执行在设计应用程序或功能时定义的规则和约束。既规定了当给定场景发生时应用程序应该如何反应（包括防止用户做将对业务产生负面影响）
4、绕过：逻辑中的缺陷会使攻击者绕过这些规则。如可能能够完成一个事务，而不需要通过预期的购买工作流。在其他情况下，对用户提供的数据的验证被破坏或不存在，可能会允许用户对事务关键值进行任意更改或提交无意义的输入。通过向服务器端逻辑传递意外值，攻击者可能会诱使应用程序执行不应该执行的操作。
5、识别：基于逻辑的漏洞可能极其多样，并且通常是应用程序及其特定功能所特有的。识别它们通常需要一定的人类知识，例如对业务领域的了解或攻击者在给定上下文中可能具有的目标。这使得使用自动漏洞扫描程序很难检测到它们。因此，逻辑缺陷通常是错误赏金猎人和手动测试人员的一个很好的目标。
2、业务逻辑漏洞的产生
1、缺陷的假设：业务逻辑漏洞的出现通常是因为设计和开发团队对用户将如何与应用程序交互做出了有缺陷的假设。这些错误的假设可能导致用户输入的验证不充分。如开发人员假设用户将专门通过Web浏览器传递数据，则应用程序可能完全依赖于弱客户端控件来验证输入。攻击者使用拦截代理很容易绕过这些漏洞
2、结果：当攻击者偏离预期的用户行为时，应用程序无法采取适当的步骤来防止这种情况，从而无法安全地处理这种情况
3、发现：逻辑缺陷在过于复杂的系统中特别常见，甚至开发团队自己也不完全理解。为了避免逻辑缺陷，开发人员需要从整体上理解应用程序。这包括了解如何以意想不到的方式组合不同的功能。处理大型代码库的开发人员可能并不完全了解应用程序的所有方面是如何工作的。从事一个组件工作的人可能会对另一个组件的工作方式做出有缺陷的假设，结果无意中引入了严重的逻辑缺陷。如果开发人员没有明确地记录所做的任何假设，这类漏洞很容易潜入应用程序
3、产生的影响
1、危害看如何利用：业务逻辑漏洞的影响有时可能相当微不足道，其影响千差万别。但如果攻击者能够以正确的方式操纵应用程序，则任何意外行为都可能导致高严重性攻击（出于这个原因，即使你自己不知道如何利用古怪的逻辑，理想的情况下也应该修复它。总是有风险，其他人将能够利用）
2、功能点：任何逻辑缺陷的影响都取决于它与什么功能相关。如漏洞存在于身份验证机制中，这可能会对您的整体安全性产生严重影响。攻击者可能会利用此漏洞进行权限提升，或完全绕过身份验证，从而获得对敏感数据和功能的访问权限，这也增加了其他攻击的攻击面。（又如财务交易中的逻辑缺陷显然会通过资金被盗、欺诈等方式导致企业遭受巨大损失）
3、受益者：即使逻辑缺陷可能不允许攻击者直接受益，但它们仍然可能允许恶意方以某种方式损害业务
二、过度信任客户端控件
1、简述
1、用户可控数据：一个根本性的错误假设是用户将只通过提供的Web界面与应用程序交互。这是特别危险的，因为它导致进一步假设客户端验证将防止用户提供恶意输入。但攻击者可以简单地使用Burp Proxy等工具，在浏览器发送数据之后、传递到服务器端逻辑之前篡改数据。这实际上使客户端控件变得无用
2、数据完整性检测：如果只接受数据的表面价值，而不执行适当的完整性检查和服务器端验证，攻击者就可以以相对最小的努力进行各种破坏。它们能够实现的具体效果取决于功能以及它对可控数据所做的操作。在适当的情况下，这种缺陷可能会对业务相关功能和网站本身的安全性造成破坏性后果。
3、涉及实验：
实验1：过度信任客户端控件
身份认证漏洞-实验8：2FA断开逻辑
（【bp靶场portswigger-服务端2】身份认证漏洞-16个实验（全））
实验1：过度信任客户端控件
信息：
购买夹克
已有账号：wiener/peter
part1：
先登录
part2：
先走一遍购物的流程，然后分析这个过程所产生的数据包（BP）
首页去购买商品
添加到购物车
点击购物车
点击购买
提示：没有足够的商店积分用于此购买
part3：
分析数据包（HTTP历史记录）
流程为：添加商品到购物车--->生成订单--->支付订单
（一般第一步的数据传输直接影响到后面步骤）
添加商品到购物车（带有重要的价格数据）
part4：
发送到repeater
修改价格为0
（302跳转，和原来数据响应一样）
但是 刷新购物车没有商品（所以价格可能不能为0）
价格修改为1
刷新购物车（发现价格变了，且是0.01）
（我们有100.00，所以可以购买了）
点击购买
三、未处理非常规输入
1、简述
1、数据类型：应用程序逻辑的一个目的是将用户输入限制为符合业务规则的值。如应用程序可能被设计为接受某种数据类型的任意值，但是逻辑从业务的角度确定该值是否可接受。许多应用程序将数字限制合并到其逻辑中。这可能包括为管理库存、应用预算限制、触发供应链阶段等而设计的限制。
2、限制：（以网上商店为例）订购产品时，用户通常指定他们想要订购的数量。尽管理论上任何整数都是有效的输入，但是业务逻辑可能会阻止用户订购超过当前库存的单位。
3、处理规则：要实现这样的规则，开发人员需要预测所有可能的场景，并将处理这些场景的方法合并到应用程序逻辑中。即它们需要告诉应用程序是否应该允许给定的输入，以及它应该如何基于各种条件做出反应。如果没有用于处理给定情况的显式逻辑，则可能导致意外和潜在的可利用行为。
4、示例：数字数据类型可能接受负值。根据相关功能的不同，业务逻辑允许这样做可能没有意义。但如果应用程序没有执行足够的服务器端验证并拒绝此输入，攻击者可能会传入负值并引发不需要的行为。
1）两个银行帐户之间的资金转帐。此功能几乎肯定会在完成转账之前检查发送方是否有足够的资金
2）但如果逻辑不足以防止用户在amount数量参数修改，攻击者可以利用此漏洞绕过余额检查并向"错误"方向转移资金。如果攻击者向受害者的帐户发送了-1000，这可能会导致他们从受害者那里收到1000。该逻辑将始终计算-1000小于当前余额，并批准转帐。
3）像这样简单的逻辑缺陷如果出现在正确的功能中，可能是毁灭性的。在开发和测试过程中，它们也很容易被忽略，特别是在Web界面上的客户端控件可能会阻止此类输入的情况下。
4）尝试输入合法用户不太可能输入的范围。这包括异常高或异常低的数字输入以及基于文本的字段的异常长的字符串。您甚至可以尝试意外的数据类型。通过观察应用程序的响应（考虑限制、极限、转化、规范化）
5、涉及实验：
实验2：高级逻辑漏洞
实验5：低级逻辑缺陷
实验6：异常输入处理不一致
实验2：高级逻辑漏洞
购买夹克
已有账号：wiener/peter
part1：
先登录
part2：
先走一遍购物的流程，然后分析这个过程所产生的数据包（BP）
首页去购买商品
添加到购物车
点击购物车
点击购买
提示：没有足够的商店积分用于此购买
part3：
分析数据包（HTTP历史记录）
流程为：添加商品到购物车--->支付订单
（一般第一步的数据传输直接影响到后面步骤）
添加商品到购物车（带有重要的数量数据）
part4：
发送到repeater
修改数量为-1
（302跳转，和原来数据响应一样）
刷新页面，并观察购物车商品数量
（1-1=0，数量为空）
尝试再重发数据包，将购物车数量变为-1
再次刷新页面，变为负数了
part5：
将皮夹克添加到购物车中（正数1）
将其他商品添加到购物车（负数）
使价格降到自己钱以下，再点击购买
（第一次使用的解法）
也购买成功，但好像不是实验需要的解法
商品价格和数量为负数肯定会有检测，尝试添加不一样的商品到购物车，但是使总价为正数
添加不同的商品
添加到
1、总价为正数
2、视屏数量为正数
点击购买
也购买成功，但好像不是实验需要的解法
实验5：低级逻辑缺陷
信息：
购买夹克
已有账号：wiener/peter
part1：
先登录
part2：
先走一遍购物的流程，然后分析这个过程所产生的数据包（BP）
首页去购买商品
添加到购物车
点击购物车
点击购买
提示：没有足够的商店积分用于此购买
part3：
分析数据包（HTTP历史记录）
流程为：添加商品到购物车--->支付订单
（一般第一步的数据传输直接影响到后面步骤）
添加商品到购物车（带有重要的数量数据）
part4：
发送到repeater
修改数量为-1
（302跳转，和原来数据响应一样）
刷新页面，并观察购物车商品数量
（1-1=0，数量为空）
尝试再重发数据包，看数量能否为负数
再次刷新页面，还是为0
再尝试是否有上限，突破上限以后是否有意想不到的效果
part5：
发送到intruder
不使用有效载荷，相当于进行重发攻击
数量改为99
自己手动的不断刷新页面，观看是否有某个临界点
发现为负数了， 且不断重放价格会变小
小到0以后，又开始正向增加
part6：
所以将价值控制到负数，然后进行下一步
通过repeater重放，将价格变回负数
part7：
将其他商品添加到购物车，使其价格为正数（且在我们现有金额100范围内）
（虽然不能直接输入大于99的，但是我们可能在数据包中然后批量重放）
发到repeater，进行数学计算后添加数额
（每次都重放99，到最后马上不够的时候计算一下，过了就将数量变为负进行减）
超过以后使用负的一点点减
小于100了，点击购买
实验6：异常输入处理不一致
信息：
未充分验证用户输入，利用账号注册接口，访问管理功能
目标删除用户
part1：
接口，我一般用的dirsearch.py去跑（获取收集到已知的目录就使用bp去跑）
管理功能（无论什么站手工必测/admin）
/admin
part2：
（此步骤只是测试）
账号注册
使用提供邮件进行注册
随便注册一个账号/密码
（这里有一个提示，使用指定的邮箱注册可以进入admin页面）
点击链接进行注册
提示：注册成功
进行登录
part3：
使用指定的 @dontwannacry.com进行注册
漏洞在于邮箱会被截短为255字符
所以使用@dontwannacry.com作为子域名（且保证后面的字符串被截断）
……@dontwannacry.com(前面一共255字符) .exploit-0a340075032599a7df0e0cf401cd00c8.exploit-server.net 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111@dontwannacry.com.exploit-0a340075032599a7df0e0cf401cd00c8.exploit-server.net
进行注册
登录账号
邮箱被截短为预设状态
part5：
完成实验
删除carlos用户
