一、业务逻辑漏洞

1、意义

2、业务逻辑漏洞的产生

3、产生的影响

二、过度信任客户端控件

1、简述

实验1：过度信任客户端控件

三、未处理非常规输入

1、简述

实验2：高级逻辑漏洞

实验5：低级逻辑缺陷

实验6：异常输入处理不一致

四、对用户行为做出错误的假设

1、简述

2、受信任的用户并非始终值得信赖

实验3：安全控制不一致

3、用户并不总是提供强制输入

实验7：两用终端隔离薄弱

4、用户并不总是按照预期的顺序

实验8：工作流程确认不充分

实验9：通过有缺陷的状态机绕过认证

四、特定领域缺陷

1、简述

实验4：业务规则的实施存在缺陷

实验10：无限货币逻辑缺陷

五、提供加密预言

1、简述

实验11：通过加密Oracle绕过认证（问题：填入的值被置空）

一、业务逻辑漏洞

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用户

四、对用户行为做出错误的假设

1、简述

最常见的根本原因之一逻辑脆弱性对用户行为做出错误的假设。如果开发人员没有考虑到违反这些假设的潜在危险场景，这可能会导致各种各样的问题

2、受信任的用户并非始终值得信赖

1、信任期限：应用程序可能看起来很安全，因为它们实现了看似健壮的措施来强制执行业务规则。不幸的是，一些应用程序错误地认为，在最初通过这些严格的控制之后，用户及其数据可以无限期地受到信任。这可能导致从那时起对相同控制的执行相对宽松。

2、一致性：如果在整个应用程序中没有一致地应用业务规则和安全措施，则可能会导致潜在的危险漏洞，攻击者可能会利用这些漏洞。

3、涉及实验：
实验3：安全控制不一致

实验3：安全控制不一致

信息：

和上一题一样

part1：

先注册一个账号

邮箱：
attacker@exploit-0a8f00ce0368d12cc099127a0169003c.exploit-server.net
完成注册

进行登录

part2：

修改邮箱（后缀为@dontwannacry.com的邮箱）

part3：

完成实验

3、用户并不总是提供强制输入

1、数据篡改：一个误解是用户总是为强制输入字段提供值。浏览器可能会阻止普通用户提交不需要输入的表单，但正如我们所知，攻击者可以在传输过程中篡改参数。这甚至可以扩展到完全删除参数。

2、数据间的联系：在同一个服务器端脚本中实现多个函数的情况下，这是一个特殊的问题。在这种情况下，特定参数的存在与否可以确定执行哪个代码。删除参数值可能允许攻击者访问本应无法访问的代码路径

3、寻找：当探测逻辑缺陷时，应该尝试依次删除每个参数，并观察对响应的影响

一次只移除一个参数，确保到达所有相关的代码路径
尝试删除参数的名称和值。服务器通常会以不同的方式处理这两种情况
遵循多阶段流程直至完成。有时候，在一个步骤中篡改参数会影响工作流中的另一个步骤

（适用于URL和POST参数，同时检查cookie）

涉及实验：

实验7：两用终端隔离薄弱
身份认证漏洞-实验3：密码重置逻辑错误

（【bp靶场portswigger-服务端2】身份认证漏洞-16个实验（全））

实验7：两用终端隔离薄弱

信息：

权限级别设置有缺陷

已有账号：wiener/peter

part1：

登录已有账号

漏洞点在于，将原密码（current-password参数）删除任然可以修改密码

对administrator密码进行重置操作

删除了current-password参数

修改数据包，并关闭拦截

提示修改成功

part2：

完成实验

administrator登录

删除用户

4、用户并不总是按照预期的顺序

1、许多事务依赖于由一系列步骤组成的预定义工作流。Web界面通常会引导用户完成此过程，并在每次完成当前步骤时将他们带到工作流的下一步。但攻击者不一定会遵守这个预期的顺序。不考虑这种可能性可能会导致危险的缺陷，而这些缺陷可能相对容易利用

2、如许多实施双因素身份验证（2FA）的网站要求用户在一个页面上登录，然后在另一个页面上输入验证码。假设用户将始终遵循此过程直到完成，结果是不验证他们是否遵循此过程，可能会使攻击者完全绕过2FA步骤。

3、涉及实验：身份认证漏洞-实验2：2FA简单旁路

【bp靶场portswigger-服务端2】身份认证漏洞-16个实验（全）

4、不可预测性：即使在相同的工作流或功能中，对事件的顺序进行假设也可能导致广泛的问题。使用Burp Proxy和Repeater等工具，一旦攻击者看到请求，就可以随意重放请求，并使用强制浏览以任何顺序执行与服务器的任何交互。这允许它们在应用程序处于意外状态时完成不同的操作

5、寻找缺陷：要识别这些类型的缺陷，应该使用强制浏览来以非预期的顺序提交请求。如可能跳过某些步骤、多次访问单个步骤、返回到前面的步骤等。请注意访问不同步骤的方式。尽管通常只是向特定的URL提交GET或POST请求，但有时可以通过向同一URL提交不同的参数集来访问步骤。与所有逻辑缺陷一样，尝试确定开发人员做出了哪些假设以及攻击面在哪里。然后可以寻找违反这些假设的方法

（这种测试通常会导致异常，因为预期的变量具有空值或未初始化的值。在部分定义或不一致的状态下到达某个位置也可能导致应用程序报错。在这种情况下，务必密切注意遇到的任何错误消息或调试信息。这些都是有价值的信息公开，这可以帮助微调攻击并了解有关后端行为的关键详细信息）

6、涉及实验：

实验8：工作流程确认不充分
实验9：通过有缺陷的状态机绕过认证

实验8：工作流程确认不充分

信息：

工作流程顺序存在缺陷

已有账号：wiener:peter

part1：

登录账号

part2：

实现完整的购买流程（购买成功的流程）

将100以内的商品加到购物车

进入购物车，并购买

购买成功

/cart是添加到购物车

part3：

失败的购买流程

和上一步一样，但是购买的是夹克（钱不够）

part4：

分析数据包

对比发现，不同的地方就是这个地方
购买成功：
/cart/order-confirmation?order-confirmed=true

购买失败：
/cart?err=INSUFFICIENT_FUNDS
part5：

将夹克添加到购物车

重放购买成功的这个数据包

刷新页面

（发现购物车商品被购买清空）

实验9：通过有缺陷的状态机绕过认证

信息：

登录过程的顺序存在缺陷

存在/admin路径

已知账号：wiener:peter

part1：

使用已有账号，完成登录的流程

选角色（随便选一个）

流程的数据包

part2：

漏洞点是，丢掉选角色的数据包，将以管理员身份登录

进行重新登录，且拦截数据包

先关闭浏览器接收请求

再丢掉数据包

（避免接收到报错页面）

part3：

完成实验

回到首页，已经有admin权限

四、特定领域缺陷

1、简述

1、功能导向：在许多情况下，会遇到特定于业务领域或站点用途的逻辑缺陷

2、交易功能：在线商店的折扣功能是寻找逻辑缺陷的经典攻击面。对于攻击者来说，这可能是一个潜在的金矿，在折扣应用的方式中会出现各种基本的逻辑缺陷。

3、示例：一家在线商店对超过1000美元的订单提供10%的折扣。如果业务逻辑无法检查在应用折扣后订单是否发生了更改，那么这可能会被滥用。在这种情况下，攻击者只需向购物车中添加商品，直到达到1000美元的阈值，然后在下订单之前删除不想要的商品。然后，即使订单不再满足预期标准，也会收到订单折扣

4、了解算法：应该特别注意根据用户操作确定的标准调整价格或其他敏感值的任何情况。试着了解应用程序使用什么算法来进行这些调整，以及在什么时候进行这些调整。这通常涉及操纵应用程序，以使其处于所应用的调整不对应于开发人员所期望的原始标准的状态。

5、掌握业务知识：要识别这些漏洞，需要仔细考虑攻击者可能具有的目标，并尝试使用提供的功能找到实现此目标的不同方法。这可能需要一定程度的特定领域知识，以便了解在特定情况下什么可能是有利的。举个简单的例子，你需要了解社交媒体，才能理解强迫大量用户追随你的好处

————

如果没有这方面的知识，你可能会忽视危险的行为，因为你根本没有意识到它潜在的连锁反应。同样地，你可能很难把这些点连接起来，并注意到两个功能是如何以有害的方式结合在一起的

6、涉及实验：

实验4：业务规则的实施存在缺陷
实验10：无限货币逻辑缺陷

实验4：业务规则的实施存在缺陷

信息：

采购流程存在缺陷

已有账号：wiener:peter

part1：

进入靶场，还未登录就提供了一张优惠券代码

应该是优惠券叠加了

优惠券1：NEWCUST5

使用已有账号登录

wiener:peter

part2：

现在考虑再注册账号，或者其他方法获得新优惠券

首页底部（注册以后会提供一个新的优惠券2）

优惠券2：SIGNUP30

part3：

优惠券叠加支付购买夹克

优惠券1：NEWCUST5

优惠券2：SIGNUP30

（添加优惠券地方）

如果连续两次输入相同的代码，它将被拒绝，因为优惠券已经被应用。但是，如果在这两个代码之间交替使用，则可以绕过此控制

实验10：无限货币逻辑缺陷

信息：

采购流程上存在缺陷

已有账号：wiener:peter

part1：

先登录

漏洞点关于礼品卡

购买礼品卡

优惠券：SIGNUP30

最后10元的礼品券只用花7元

获取到礼品卡

N2HtusPj6Z

兑换礼品卡

然后赚了3块钱

【100-（10-3）+10】=103

part2：

分析数据包
逻辑：

1、添加到购物车：POST/cart
2、优惠券：POST/cart/coupon
3、结账：POST/cart/checkout
4、清空购物车，购买成功：GET/cart/order-confirmation?order-confirmed=true
5、礼品卡：POST/gift-card
part3：

使用宏编辑器

（这个地我配置错了一个，然后马上改过来了）

（下面这张图错了一个地方）

要取的是code那里

改正：

连点4个ok

part4：

主页数据包

****提醒***

踩坑：线程一定要设置为1（后面有我多线程跑的结果）

开始攻击

part5：

钱会自己每次多3块

刷新页面可以看见有多少钱了（钱够了就去买夹克）

钱够了，买夹克去

（多线程跑的特殊错误结果）

刷新购物车页面

去买夹克

五、提供加密预言

1、简述

1、加密复用：当用户可控制的输入被加密并且所得到的密文然后以某种方式对用户可用时，可能发生危险的情形。这种输入有时被称为“加密预言”。攻击者可以使用此输入，通过正确的算法和非对称密钥加密任意数据

2、加密载荷转移：当应用程序中有其他用户可控制的输入需要使用相同算法加密的数据时，这就变得很危险。在这种情况下，攻击者可能会使用加密oracle生成有效的加密输入，然后将其传递给其他敏感函数

3、反向功能：如果在站点上存在提供反向功能的另一个用户可控输入，则这个问题可能会变得复杂。这将使攻击者能够解密其他数据以识别预期的结构。这为他们节省了一些创建恶意数据的工作，但不一定是成功利用漏洞所必需的

4、加密oracle的严重性取决于哪些功能也使用与oracle相同的算法。

5、涉及实验：

实验11：通过加密Oracle绕过认证

实验11：通过加密Oracle绕过认证（问题：填入的值被置空）

信息：

向用户公开的加密的逻辑缺陷（漏洞是关于cookie的加密机制、评论处）

目标：删除carlos用户

已有账号：wiener:peter

part1：

漏洞是关于cookie的加密机制

使用已有账号登录，收集登录的数据包

登录请求的响应包中，返回了cookie

stay-logged-in
session

在主页数据包只有stay-logged-in、session

说明是通过这2参数鉴别身份

part2：

（加密机制存在缺陷的地方：评论区）

抓取评论时候的数据包，发送到repeater

正常的评论

当修改邮箱为错误格式的时候，会设置一个notification的值

part3：

拦截后修改为错误格式

并分析报错以后的数据包

HTTP历史记录中分析

邮箱错误时设置的notification值

在响应中发现notification值被解密

（22222是我第二次尝试的时候改的）

part4：

遇到了问题：填入的值被置空

将登录时候产生的 stay-logged-in值复制到此处尝试解密

将stay-logged-in的值填到notification进行解密

但是我把加密的东西填到这里以后，这里的值被置空了

后来尝试了一下拦截返回数据包set-cookie的值，并修改

最后还是被置空