业务漏洞初探

合集 - burpsuite靶场学习(12)

1.API初探2024-12-112.XSS初探及实验2024-11-07

3.业务漏洞初探2024-11-06

4.命令注入初探2024-11-295.条件竞争初探2024-11-066.SSRF初探2024-11-067.服务器端漏洞基础2024-11-068.访问控制与权限提升初探2024-11-069.XXE初探2024-11-0610.nosql注入初探2024-11-0611.SQL注入备忘录2024-11-0612.SQL注入初探2024-11-06

收起

一、 前置了解知识

1. 什么是业务逻辑漏洞？

​ 业务逻辑漏洞是应用程序设计和实现中的缺陷，允许攻击者引发意外行为。这可能使攻击者能够操纵合法功能来实现恶意目标。这些缺陷通常是由于未能预测可能发生的异常应用程序状态，因此无法安全地处理它们。

​ 在此上下文中，术语“业务逻辑”仅指定义应用程序如何运行的一组规则。由于这些规则并不总是与业务直接相关，因此相关的漏洞也称为“应用程序逻辑漏洞”或简称为“逻辑缺陷”。

​ 逻辑缺陷对于没有明确寻找它们的人来说通常是不可见的，因为它们通常不会通过正常使用应用程序而暴露出来。但是，攻击者可能能够通过以开发人员从未想过的方式与应用程序交互来利用行为怪癖。

​ 业务逻辑的主要目的之一是强制执行在设计应用程序或功能时定义的规则和约束。从广义上讲，业务规则规定了应用程序在发生给定方案时应如何响应。这包括防止用户做对业务产生负面影响或根本没有意义的事情。

​ 逻辑中的缺陷可能允许攻击者规避这些规则。例如，他们可能能够在不完成预期购买工作流程的情况下完成交易。在其他情况下，对用户提供的数据的损坏或不存在的验证可能允许用户对事务关键值进行任意更改或提交无意义的输入。通过将意外值传递到服务器端逻辑中，攻击者可能会诱使应用程序执行不应执行的操作。

​ 基于逻辑的漏洞可能非常多样化，并且通常是应用程序及其特定功能所独有的。识别它们通常需要一定量的人类知识，例如对业务领域的理解或攻击者在给定上下文中可能具有的目标。这使得使用自动漏洞扫描程序难以检测它们。因此，逻辑缺陷是漏洞赏金猎人和手动测试人员的一个很好的目标。

2. 业务逻辑漏洞是如何产生的？

​ 业务逻辑漏洞的出现通常是因为设计和开发团队对用户将如何与应用程序交互做出了有缺陷的假设。这些错误的假设可能导致对用户输入的验证不充分。例如，如果开发人员假设用户将仅通过 Web 浏览器传递数据，则应用程序可能完全依赖弱客户端控件来验证输入。攻击者使用拦截代理很容易绕过这些漏洞。

​ 最终，这意味着当攻击者偏离预期的用户行为时，应用程序无法采取适当的措施来防止这种情况发生，从而无法安全地处理这种情况。

​ 逻辑缺陷在过于复杂的系统中尤为常见，甚至开发团队自己也无法完全理解。为了避免逻辑缺陷，开发人员需要将应用程序作为一个整体来理解。这包括了解如何以意想不到的方式组合不同的功能。使用大型代码库的开发人员可能不了解应用程序的所有区域的工作方式。在一个组件上工作的人可能会对另一个组件的工作方式做出错误的假设，结果，无意中引入了严重的逻辑缺陷。如果开发人员没有明确记录所做的任何假设，则这些类型的漏洞很容易潜入应用程序。

3. 业务逻辑漏洞有何影响？

​ 业务逻辑漏洞的影响有时可能相当微不足道。这是一个广泛的类别，影响变化很大。但是，如果攻击者能够以正确的方式操纵应用程序，则任何意外行为都可能导致高严重性攻击。出于这个原因，理想情况下，即使你不能自己弄清楚如何利用它，古怪的逻辑也应该被修复。总是存在其他人能够做到的风险。

​ 从根本上说，任何逻辑缺陷的影响都取决于它与什么功能相关。例如，如果缺陷存在于身份验证机制中，则可能会对整体安全性产生严重影响。攻击者可能会利用此漏洞进行权限提升，或完全绕过身份验证，从而访问敏感数据和功能。这也暴露了其他漏洞的攻击面增加。

​ 金融交易中的逻辑有缺陷显然会通过被盗资金、欺诈等方式给企业带来巨大损失。

​ 您还应该注意，即使逻辑缺陷可能无法让攻击者直接受益，它们仍可能允许恶意方以某种方式损害业务。

4. 如何防止业务逻辑漏洞

​ 简言之，防止业务逻辑漏洞的关键是：

• 确保开发人员和测试人员了解应用程序所服务的域
• 避免对用户行为或应用程序其他部分的行为做出隐式假设

​ 您应确定对服务器端状态所做的假设，并实现必要的逻辑来验证这些假设是否得到满足。这包括在继续之前确保任何输入的值是合理的。

​ 确保开发人员和测试人员都能够完全理解这些假设以及应用程序在不同场景中应该如何反应也很重要。这可以帮助团队尽早发现逻辑缺陷。为此，开发团队应尽可能遵循以下最佳实践：

• 为所有事务和工作流程维护清晰的设计文档和数据流，并注意每个阶段所做的任何假设。
• 尽可能清晰地编写代码。如果很难理解应该发生的事情，就很难发现任何逻辑缺陷。理想情况下，编写良好的代码不需要文档来理解它。在不可避免的复杂情况下，生成清晰的文档对于确保其他开发人员和测试人员知道正在做出的假设以及预期的行为的确切内容至关重要。
• 请注意对使用每个组件的其他代码的任何引用。想想如果恶意方以不寻常的方式操纵这些依赖关系的任何副作用。

​ 由于许多逻辑缺陷的相对独特性，很容易将它们视为人为错误导致的一次性错误并继续前进。但是，正如我们所演示的，这些缺陷通常是构建应用程序初始阶段不良做法的结果。首先分析为什么存在逻辑缺陷，以及团队是如何遗漏的，可以帮助您发现流程中的弱点。通过进行细微的调整，您可以增加在源头上切断类似缺陷或在开发过程早期捕获的可能性。

二、 实际操作案例

1. 对客户端控件的过度信任

一个从根本上有缺陷的假设是，用户只能通过提供的 Web 界面与应用程序进行交互。这尤其危险，因为它会导致进一步的假设，即客户端验证将阻止用户提供恶意输入。但是，攻击者可以简单地使用Burp Proxy等工具在浏览器发送数据后，但在数据传递到服务器端逻辑之前篡改数据。这实际上使客户端控件变得无用。

在不执行适当的完整性检查和服务器端验证的情况下接受表面数据，可以使攻击者以相对较少的努力造成各种损害。他们能够实现的确切目标取决于功能以及它对可控数据的处理方式。在正确的上下文中，这种缺陷可能会对与业务相关的功能和网站本身的安全性产生毁灭性的后果。

购买商品的简单逻辑

通过实验来了解，首先在购买商品的时候，选择把商品添加的购物车，那么抓取这个商品到购物车的数据包，看能否修改一些价格之类的参数，来使得在加入到购物车之后，价格与原本的并不相同，这就产生了所谓的相信客户端控件的漏洞。

登录界面的简单逻辑

这种所产生的漏洞，也可用于登录时的绕过，如2FA的登录。这种都是容易产生所谓的逻辑漏洞的地方

以之前的 2FA broken logic 实验来说。

在登录一个已经有的账号时，通过抓取数据包，发现在登录后的一个数据包中，是通过cookie中的一个值来发送验证码的，而这个值就是用户名。

那么就可以测试，如果把这个值改为另一个账号，那么验证码就会发送到另一个账号的邮箱。那么此时的登录算谁的呢，前面虽然是用的原账号，但是在发送验证码的时候，修改成另一个账号了，也就导致原账号并没有收到验证码，另一个账号收到了。

如果服务器并没有检测另一个账号是否有登录的过程，那么这里就可以直接对验证码进行爆破。以此直接输入验证码就可以登录到其账号。

主要的逻辑在于，如果一个账号登录了，后面的验证码等过程，只检测cookie中的某一个值，那就导致修改这个值，以达到逻辑绕过

2. 无法处理非常规输入

应用程序逻辑的一个目标是将用户输入限制为符合业务规则的值。例如，应用程序可能被设计为接受特定数据类型的任意值，但从业务的角度来看，逻辑决定了此值是否可接受。许多应用程序将数值限制纳入其逻辑中。这可能包括旨在管理库存、应用预算限制、触发供应链阶段等的限制。

让我们以网上商店为例。订购产品时，用户通常会指定要订购的数量。尽管理论上任何整数都是有效的输入，但业务逻辑可能会阻止用户订购比当前库存更多的单位。

为了实现这样的规则，开发人员需要预测所有可能的情况，并将处理这些情况的方法合并到应用程序逻辑中。换句话说，他们需要告诉应用程序是否应该允许给定的输入，以及它应该如何根据各种条件做出反应。如果没有用于处理给定案例的显式逻辑，则可能导致意外且可能被利用的行为。

例如，数值数据类型可能接受负值。根据相关功能，业务逻辑可能不允许这样做。但是，如果应用程序未执行足够的服务器端验证并拒绝此输入，则攻击者可能能够传入负值并诱发不需要的行为。

考虑在两个银行账户之间进行资金转账。在完成转账之前，此功能几乎肯定会检查汇款人是否有足够的资金：

$transferAmount = $_POST['amount']; 
$currentBalance = $user->getBalance(); 
if ($transferAmount <= $currentBalance) {    
    // Complete the transfer 
} 
else {    
    // Block the transfer: insufficient funds 
}

但是，如果逻辑不足以阻止用户在参数中提供负值，攻击者可能会利用这一点绕过余额检查并在“错误”方向转移资金。如果攻击者向受害者的帐户发送 -1000 美元，这可能会导致他们从受害者那里收到 1000 美元。逻辑将始终评估 -1000 小于当前余额并批准转移。amount

像这样的简单逻辑缺陷，如果它们发生在正确的功能中，可能是毁灭性的。在开发和测试过程中，它们也很容易被遗漏，特别是考虑到此类输入可能会被 Web 界面上的客户端控件阻止。

审核应用程序时，应使用 Burp Proxy 和 Repeater 等工具尝试提交非常规值。特别是，尝试在合法用户不太可能输入的范围内输入。这包括异常高或异常低的数字输入以及基于文本的字段的异常长字符串。您甚至可以尝试意外的数据类型。通过观察应用程序的响应，您应该尝试回答以下问题：

• 对数据是否有任何限制？
• 当你达到这些限制时会发生什么？
• 是否正在对输入执行任何转换或规范化？

这可能会暴露弱输入验证，从而允许您以不寻常的方式操作应用程序。请记住，如果您在目标网站上发现一个表单无法安全地处理非常规输入，则其他表单可能会遇到相同的问题。

高级逻辑漏洞

通过这个实验室，首先还是抓取数据包进行分析测试。

这里首先还是加入购物车，然后在加入的过程中，抓取数据包，发现没有价格可以修改，但是有一个数量的值，测试能否修改为负数，发现可以。但是在支付时，提示不允许总价格小于0，也就是虽然修改成了负数的，但是无法支付，其实也无法获得这个商品

但是，换个方式思考，既然这里的总金额是负数，那么是否可以再往购物车里添加商品，直至我的总价格不小于0，也能够以最少的钱买到更多的商品，因为这里有个负的金额在垫着。

低级逻辑缺陷

首先还是抓取数据包进行测试，这里可以修改数量，但是修改为负数时，添加不进去购物车。这里的数量被限制为整数，那么就尝试突破到整数所支持的最大值进行测试，看能否改变。当数量超过某一个值的时候，总价格改变，从正数开始忙忙的往负数发展。

价格已超过后端编程语言中整数允许的最大值 （2,147,483,647）。因此，该值已循环回到最小可能值 （-2,147,483,648）。

这个时候，只需要把总价格重新构造在0-100之间，因为账号只有100。这里请求其他的产品，使用burp的intruder模块进行慢慢的请求即可。其实也可以一直买一个，但是这个有时候可能不好控制，或者在实际中，很少有人能够买到整数的最大值，所以需要其他的商品来掩饰。当知道有这种最大值的漏洞时，就可以通过买其他的东西来掩饰这个过程

对异常输入的处理不一致

未充分验证用户输入。您可以利用其帐户注册过程中的逻辑缺陷来访问管理功能

主要是通过服务器对注册账号时的邮箱处理不一致。如用户输入一个超长的邮箱地址，然后注册，但是点击注册后，服务器直接发送给这个邮箱一个链接地址，然后激活，但是存储在数据库中的邮箱地址就不一样了，比如因为设置问题，在mail那个元组只给了255个字符的空间，但是用户输入的是超长的邮箱地址，也就是存入数据库的邮箱地址会被截断，以至于不是原本的邮箱地址。

那么这个就可以直接注册一个原本不是这个公司内部邮箱域名的账号，但是这里需要有邮箱服务器可以接受这个激活链接。

如：当邮箱长度大于255时会被截断存放数据库。而且知道公司内部人员的邮箱域名。这时候就可以利用邮箱服务器进行构造一个长邮箱地址。

@公司内部邮箱域名.com.邮箱服务器域名.com

这个时候设置邮箱服务器可以接受到种链接的邮件。然后在@符号前构造超长链接，直到加上@公司内部邮箱域名.com时的长度正好是255时，就可以进行注册了，然后就可以注册成功，并且数据库存储的是公司内部的邮箱，当使用这个邮箱登录时，大概率就会以公司内部人员的身份登录进去，查看对应的邮件以及操作了

首先使用burp中的target中的discover content进行目录的内容扫描，发现有个admin目录，访问后发现必须是这个公司DontWannaCry的用户才行

在注册页面的时候，提示这个公司的用户该怎么注册

因为没有这个邮箱地址，所以不会接收到邮件的，先以自己的邮箱进行注册进行测试，发现注册后，邮箱发送激活链接，然后登录后，可以看到注册时使用的邮箱地址。一般存入到数据库中的东西可能会有长度的限制，如果后端代码没有进行检测直接存入数据库的话，长度超过，一般数据库都会进行截断处理。

复制回显的邮箱地址，看看在哪里被截断，以确定最大字符数，这里复制后确定255个字符，所以下面构造的时候就可以尝试。构造一个刚好截断就是公司的邮箱地址的邮箱地址。

3. 对用户行为做出有缺陷的假设

逻辑漏洞最常见的根本原因之一是对用户行为做出有缺陷的假设。这可能会导致开发人员没有考虑违反这些假设的潜在危险场景的广泛问题。在本节中，我们将提供一些应避免的常见假设的警示示例，并演示它们如何导致危险的逻辑缺陷。

受信任的用户不会始终保持可信

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

如果业务规则和安全措施未在整个应用程序中一致地应用，则可能导致攻击者可能利用的潜在危险漏洞。

安全控制不一致

有缺陷的逻辑允许任意用户访问仅应由公司员工使用的管理功能

这个虽然注册的时候可以设置邮箱，但是超长邮箱地址已经不行了

但是注册一个账号后会有一个更新邮箱的操作，可以通过在前面注册的时候，注册这个公司的邮箱，@dontwannacry.com，假设注册的时候，注册用户名为asdad(随便输入的)，邮箱为carlos@dontwannacry.com,发现提示该邮箱已被注册的话，就可以返回之前登录的时候可以更改邮箱的界面，尝试直接更改为这个邮箱，发现成功。

个人估计是虽然代码中加入了检测超长邮箱的情况，但是在更新这里没有先进行邮箱检测，如果数据库中已经有其他的账号有该邮箱，应该不让修改，这里直接就调用了数据库中的语句，修改了邮箱.

用户不会始终提供强制性输入

一个误解是，用户将始终为必填输入字段提供值。浏览器可能会阻止普通用户在没有所需输入的情况下提交表单，但正如我们所知，攻击者可以篡改传输中的参数。这甚至扩展到完全删除参数。

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

在探测逻辑缺陷时，应尝试依次删除每个参数，并观察这对响应的影响。您应该确保：

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

这适用于 URL 和POST参数，但不要忘记检查 cookie。这个简单的过程可以揭示一些可能被利用的奇怪的应用程序行为。

两用端点上的弱隔离

据用户的输入对用户的权限级别做出了有缺陷的假设。因此，您可以利用其帐户管理功能的逻辑来访问任意用户的帐户。

像上面描述的，在探测逻辑缺陷时，应尝试依次删除每个参数，并观察这对响应的影响。

这个实验中的缺陷是，后端代码没有对修改密码时的当前密码进行验证，其实好多地方也是有直接提供新密码的，没有提交当前密码的选择。

主要是在测试逻辑漏洞时，有参数的情况下，尝试参数之间的不同搭配会有什么响应，或者少参数的情况，又是怎样的。

这里直接抓取数据包，然后把当前密码的参数删除掉，即可修改别的账号的密码。

密码重置逻辑损坏

之前实验做过，这个也是逻辑型的考察，这里首先忘记密码，使用自己的账号先进行测试，并在每个过程抓取数据包进行分析，这个忘记密码的链接是通过邮件重置的，所以，如果没有那个账号的邮箱，不能进行测试，继续往下走，发现在点击邮箱链接的时候，数据包中有明显的账号信息，也就是这个重置链接需要带着用户名才直到重置的是谁，这里直接修改其他用户名，修改密码成功

用户不会总是遵循预期的顺序

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

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

2FA 简单旁路

无权访问用户的 2FA 验证码，但可以绕过此实验室的双因素身份验证

和之前的实验一样，这里是登录账号后，会有一个需要填写的验证码，这个验证码通过邮箱发送。经自己的账号测试。所以这个验证流程是这样的：

输入账号密码----->输入验证码------>显示登录成功

那么这种验证过程如果有一步不是这个流程会怎么样呢，在输入验证码的时候，发现有其他模块可以登录，点击后，发现跳转到主页，当再点击回账号时，发现已经登录成功，并没有输入验证码。

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

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

请注意，这种测试通常会导致异常，因为预期变量具有 null 值或未初始化的值。到达处于部分定义或不一致状态的位置也可能导致应用程序抱怨。在这种情况下，请务必密切注意遇到的任何错误消息或调试信息。这些可能是信息泄露的宝贵来源，可以帮助您微调攻击并了解有关后端行为的关键细节。

工作流程验证不足

实验对采购工作流中的事件顺序做出了有缺陷的假设

首先登录账号，然后把之前能修改的地方进行测试，发现都不行， 那么这里考虑流程，也就是加入购物车，然后付款，那么付款的时候是怎么样呢，加入一个买得起的物件，抓取付款的数据包

付款的时候数据包显示，首先进行检测金额等方面，比如金额够不够，总金额是否为0一下等

然后就会重定向到检测为true的数据包，然后就支付成功了

整个过程，并没有任何地方可以修改，那么分析每个数据包，首先检测数据包，用来检测账户金额和总金额等情况的，这个并没有任何。但是会重定向到一个检测为true的界面，然后就支付成功，清空购物车，把每个数据包再单独发送一遍进行测试。

发现第二个数据包的功能，就只有清空购物车的功能，但是购物车里的东西也会被购买，并且没有支付金额。

这里留着第二个数据包，然后往购物车加入东西，直接重发第二个数据包，发现确实购买了。

这里发现，当第一个数据包发送后，再发送第二个数据包，购物车里的东西就需要支付购买了，猜测第一个数据包就是检测购物车等情况的，第二个数据包只进行清空购物车，但是清空也会购买到，只是不需要支付。

通过有缺陷的状态机绕过身份验证

实验对登录过程中的事件顺序做出了有缺陷的假设

与上一个实验一样，首先还是抓包进行分析

登录--->跳转到选择权限---->选择权限界面---->登录成功

经测试，即使跳转到选择权限，选择管理员权限依然还是普通权限，说明这个选择权限页面是有验证的，那么观察发现，登录成功后的数据包与跳转到选择权限的数据包基本一样，只是请求路径不同，那么尝试修改数据包，使得在登录时的数据包不指向选择权限，直接到登录成功，会是什么样的，允许还是不允许，允许的话，什么权限

上面是步骤的数据包，把第二个get请求中的权限选择，直接改成最后一个数据包的根目录请求。发现也是登录成功，并且是管理员权限

特定于域的缺陷

在许多情况下，您会遇到特定于业务领域或网站目的的逻辑缺陷。

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

例如，考虑一家在线商店为超过 10 美元的订单提供 10% 的折扣。如果业务逻辑在应用折扣后无法检查订单是否已更改，则此漏洞可能容易被滥用。在这种情况下，攻击者可以简单地将商品添加到购物车中，直到它们达到 1000 美元的门槛，然后在下订单之前删除他们不想要的商品。然后，即使订单不再满足预期标准，他们也将获得折扣。

您应特别注意根据用户操作确定的标准调整价格或其他敏感值的任何情况。尝试了解应用程序使用哪些算法进行这些调整，以及在何时进行这些调整。这通常涉及操作应用程序，使其处于应用的调整与开发人员预期的原始标准不符的状态。

若要识别这些漏洞，需要仔细考虑攻击者可能具有的目标，并尝试使用提供的功能找到实现此目的的不同方法。这可能需要一定程度的特定领域知识，以便了解在给定环境中可能有利的内容。举个简单的例子，你需要了解社交媒体，才能理解强迫大量用户关注你的好处。

如果没有对该领域的了解，您可能会忽略危险行为，因为您根本不知道其潜在的连锁反应。同样，您可能很难将这些点连接起来，并注意到两个功能如何以有害的方式组合在一起。为简单起见，本主题中使用的示例特定于所有用户都已经熟悉的域，即在线商店。但是，无论您是 bug 赏金狩猎、渗透测试，还是只是试图编写更安全代码的开发人员，您都可能在某些时候遇到来自不太熟悉的领域的应用程序。在这种情况下，您应该尽可能多地阅读文档，并在可能的情况下与该领域的主题专家交谈，以获得他们的见解。这听起来像是很多工作，但域越晦涩，其他测试人员就越有可能错过很多错误。

业务规则的执行存在缺陷

实验室的采购工作流程存在逻辑缺陷

这个和前面的工作流程验证不足差不多，不同的是这里对验证流程进行了检测，必须要进行第一个数据包的检测，才能完成清空购物车的请求。

这里给了一个折扣卷的兑换码，可以从这里进行测试，能否通过折扣，把金额降下去

发现使用一次后就不能再使用了，那么进行抓包分析，为什么不能再使用了呢，

成功的数据包： 使用折扣券---->跳转到购物车的界面

失败的数据包： 使用折扣券---->会请求一个折扣券已经使用过的请求----->跳转到购物车界面

也就是中间有一个数据包，如果直接跳过这个数据包呢，发现还是不行，检测还是会检测到

查找页面有无其他内容，发现底部有个注册，随便输入会给出另一张折扣券，测试是否可以叠加使用。发现两个可以一起使用，但是还是不够，所以抓包分析

两个折扣券的使用和上面的数据包流程一样，对某一个折扣券进行数据包重发，并没有产生多的折扣，那如果不是对某一个进行一直重发呢，进行交替会有什么效果。对两个数据包进行交谈重发，发现虽然请求的结果返回是已经使用了，但是在购物车里，折扣已经重复使用了。

这个就是检测的问题，是为了防止一个折扣券的多次使用，但是，检测的时候应该是对一个折扣券进行了连续检测，就是如果一个折扣券连续多次的请求，那么判断它已经被使用过，但是如果交替进行，导致检测的时候发现不是连续的，漏洞就出来了。这是代码的问题。

无限货币逻辑缺陷

实验室的采购工作流程存在逻辑缺陷

这里有一个商品，买了之后会有返现，原价返回，然后这个商店的新用户可以领取折扣券，

可以使用burp的宏功能或者写一段python脚本，进行重复的使用折扣，然后返现

提供加密预言机

当对用户可控的输入进行加密，然后以某种方式向用户提供生成的密文时，可能会发生危险情况。这种输入有时被称为“加密预言机”。攻击者可以使用此输入使用正确的算法和非对称密钥对任意数据进行加密。

当应用程序中还有其他用户可控的输入需要使用相同算法加密的数据时，这将变得危险。在这种情况下，攻击者可能使用加密预言机生成有效的加密输入，然后将其传递给其他敏感函数。

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

加密预言机的严重性取决于哪些功能也使用与预言机相同的算法。

通过加密预言机绕过身份验证

实验包含一个逻辑缺陷，该缺陷会向用户公开加密预言机