业务逻辑漏洞举例

1. 过度信任客户端控制
一个根本错误的假设是，用户只会通过web界面与应用程序交互。这尤其危险，因为它会导致进一步的假设，即客户端验证将阻止用户提供恶意输入。然而，攻击者可以简单地使用Burp Proxy等工具篡改由浏览器发送的数据，但在数据被传递到服务器端逻辑之前。这有效地使客户端控制变得无用。

接收前端提交数据，而不执行适当的完整性检查和服务器端验证，可能使攻击者以相对较小的努力进行各种破坏。它们所能达到的效果取决于其功能以及对可控数据的处理。在适当的情况下，这种缺陷可能会对商业相关的功能和网站本身的安全造成毁灭性的后果。

2. 失败处理异常输入
应用程序逻辑的目的之一是将用户输入限制为符合业务规则的值。例如，可以将应用程序设计为接受某种数据类型的任意值，但是从业务的角度来看，逻辑决定该值是否可接受。许多应用程序将数字限制加入到它们的逻辑中。这可能包括用于管理库存的限制、应用预算限制、供应链的触发阶段等等。

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

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

例如，数字数据类型可能接受负值。根据相关的功能，业务逻辑允许这样做可能没有意义。但是，如果应用程序没有执行足够的服务器端验证并拒绝此输入，攻击者可能会传入一个负值并引发不希望的行为。

考虑两个银行账户之间的资金转移。这个功能几乎肯定会检查发送者在完成转账之前是否有足够的资金:

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
    // Complete the transfer
} else {
    // Block the transfer: insufficient funds
}
但是，如果逻辑不能充分防止用户在amount参数中提供负值，那么攻击者就可能利用这一点绕过余额检查，并向“wrong”方向转移资金。如果攻击者发送-1000美元到受害者的帐户，这可能导致攻击者从受害者手里收到1000美元。逻辑判断将总是认为-1000小于当前余额正确，并批准转移。

如果这种简单的逻辑缺陷出现在正确的功能中，那么它们将是毁灭性的。它们在开发和测试期间也很容易被忽略，特别是会这么想，这些输入可能会被web界面上的客户端控件阻塞。

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

对数据有什么限制吗?

当你达到这些限制时会发生什么?

是否对输入执行了任何转换或标准化?

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

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

3.1 可信用户并不可信
应用程序可能看起来是安全的，因为它们实现了看似健壮的措施来执行业务规则。不幸的是，一些应用程序错误地认为，一旦最初通过了这些严格的控制，用户及其数据就可以无限地信任。这可能导致从那时起控制变得相对松散。

3.2 用户可能不会提供必填字段
一个误解是，用户总是会为必填字段提供值。浏览器会阻止普通用户在必填字段为空的情况下提交表单，但正如我们所知，攻击者可以在传输过程中篡改参数。这甚至可以扩展删除全部参数。

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

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

每次只删除一个参数，以确保到达所有相关的代码路径。

尝试删除参数的名称和值。服务器通常会以不同的方式处理这两种情况。

遵循多阶段流程直至完成。有时篡改一个步骤中的参数会对工作流中的另一个步骤产生影响。

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

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

例如，许多实现双因素认证(2FA)的网站要求用户先登录一个页面，然后在另一个页面输入验证码。假设用户总是遵循这个过程直到完成，结果是，不验证他们是否这样做，可能会允许攻击者完全绕过2FA步骤。

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

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

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

4. 特定领域的缺陷
在许多情况下，您将遇到特定于商业领域站点的逻辑缺陷。

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

例如，考虑一个对订单超过1000美元提供10%折扣的在线商店。如果业务逻辑未能检查折扣应用后是否更改了订单，那么这很容易被滥用。在这种情况下，攻击者可以简单地将商品添加到他们的购物车中，直到达到1000美元的阈值，然后在下订单之前删除他们不想要的商品。然后，他们将收到订单的折扣，即使订单不再满足预期的标准。

您应该特别注意这种情况，价格或其他敏感参数的值由用户控制调整。尝试理解应用程序使用什么算法来进行这些调整，以及在什么情况下进行这些调整。这通常涉及对应用程序的操作，使其处于一种状态，即应用的调整不符合开发人员预期的原始标准。

要识别这些漏洞，您需要仔细考虑攻击者可能有哪些攻击目标，并利用提供的功能尝试不同的方法实现攻击目标。这可能需要特定领域的特定知识，以便理解在给定的环境中什么可能是有利的。举个简单的例子，您需要了解社交媒体，以便了解迫使大量用户关注您的好处。

如果不了解这个领域，您可能会忽略危险的行为，因为您根本没有意识到其潜在的连锁效应。同样地，你可能会努力把这些点连接起来，并注意到这两个功能是如何以有害的方式结合在一起的。为简单起见，本主题中使用的示例特定于所有用户都熟悉的领域，即在线商店。然而，无论您是bug赏金搜索、渗透测试，还是仅仅是一个试图编写更安全代码的开发人员，您可能会在某些时候遇到来自不太熟悉领域的应用程序。在这种情况下，您应该阅读尽可能多的文档，并在可能的情况下与该领域的主题专家交谈，以获得他们的见解。这听起来可能需要大量的工作，但是这个领域越模糊，其他测试人员就越有可能漏掉许多漏洞。

5. 提供加密oracle
当对用户可控制的输入进行加密，然后以某种方式将生成的密文提供给用户时，可能会出现危险的情况。这种类型的输入有时被称为“加密oracle”。攻击者可以使用此输入，使用正确的算法和非对称密钥加密任意数据。

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

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

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