参考:The Web Application Hackers Handbook Chapter 11

了解逻辑缺陷的最好方法不是通过理论化，而是通过熟悉一些实际示例。尽管逻辑缺陷的各个实例差异很大，但是它们具有许多共同的主题，并且它们演示了人类开发人员将总是容易犯的各种错误。因此，通过研究逻辑缺陷样本而获得的见解应有助于您在完全不同的情况下发现新缺陷。

1.示例1：询问Oracle(Example 1: Asking the Oracle)

作者已经在许多不同类型的应用程序中发现了”加密预言”流的实例。他们已经在许多攻击中使用了它，从解密打印软件中的域凭据到破坏云计算。以下是在软件销售站点中发现的错误的经典示例。

1.1 功能性(The Functionality)

该应用程序实现了”记住我”功能，通过允许应用程序在浏览器中设置永久cookie，用户可以避免每次访问都登录到该应用程序。通过在由名称，用户ID和易失性数据组成的字符串上运行的加密算法，可以保护该cookie免受篡改或泄露，以确保结果价值是独一无二的，无法预测。为了确保获得访问权限的攻击者无法重放该文件，还收集了该计算机专用的数据，包括IP地址。

该cookie被认为是一种可靠的解决方案，用于保护潜在的易受攻击的所需业务功能。

该应用程序除了具有”记住我”功能外，还具有将用户的屏幕名称存储在名为ScreenName的cookie中的功能。这样，每当她下次访问站点时，用户都可以在站点的角落收到个性化的问候。认为此名称也是一条安全信息，因此认为也应对其进行加密。

1.2 假设(The Assumption)

开发人员认为，由于ScreenName cookie对攻击者的价值要比RememberMe cookie小得多，因此他们也可以使用相同的加密算法来保护它。他们没有考虑的是用户可以指定他的屏幕名称并在屏幕上查看它。这无意间使用户访问了用于保护持久身份验证令牌的加密功能（和加密密钥）RememberMe

1.3 攻击(The Attack)

在一次简单的攻击中，用户提供了他或她的RememberMe cookie的加密值来代替加密的ScreenName cookie。当向用户显示屏幕名称时，应用程序将解密该值，检查解密是否有效，然后在屏幕上打印结果。这导致以下消息：

Welcome, marcus|734|192.168.4.282750184

尽管这很有趣，但这并不一定是高风险的问题。这仅表示给定一个加密的RememberMe Cookie，攻击者可以列出内容，包括用户名，用户ID和IP地址。由于cookie中没有存储密码，因此无法立即对所获取的信息采取行动。

真正的问题来自用户可以指定其屏幕名称的事实。结果，用户可以选择此屏幕名称，例如：

admin|1|192.168.4.282750184

当用户注销并重新登录后，应用程序将对该值进行加密，并将其作为加密的ScreenName cookie存储在用户的浏览器中。如果攻击者将此加密令牌作为RememberMe cookie的值提交，则应用程序将其解密，读取用户ID，然后以管理员身份登录攻击者！即使使用三重DES加密，使用强密钥并防止重放攻击，该应用程序也可以用作”加密预言”来解密和加密任意值。

HACK STEPS
可以在不同的位置找到这种类型的漏洞的表现。示例包括帐户恢复令牌，对基于身份验证的资源的基于令牌的访问，以及任何其他需要防篡改或用户无法读取的发送到客户端的值。

1.查找在应用程序中使用加密（而非散列）的位置。确定应用程序对用户提供的值进行加密或解密的任何位置，并尝试替换应用程序中遇到的任何其他加密值。尝试在应用程序中引起一个错误，该错误会显示解密的值或在屏幕上有意显示解密的值的位置。
2.通过确定可在何处提供加密值，从而导致在应用程序的响应中显示相应的解密值，来查找” oracle泄露”漏洞。确定这是否导致泄露敏感信息，例如密码或信用卡。
3.通过确定提供明文值导致应用程序返回相应的加密值的位置来查找” oracle加密”漏洞。通过指定任意值或应用程序将处理的恶意有效负载，确定可以在何处滥用此功能。

2.示例2：欺骗密码更改功能(Example 2: Fooling a Password Change Function)

作者在金融服务公司实现的Web应用程序以及AOL AIM企业网关应用程序中都遇到了此逻辑缺陷。

2.1 功能性(The Functionality)

该应用程序为最终用户实现了密码更改功能。它要求用户填写用户名，现有密码，新密码和确认新密码的字段。

2.2 假设(The Assumption)

呈现给用户和管理员的客户端界面在一个方面有所不同：管理员界面不包含现有密码的字段。当服务器端应用程序处理密码更改请求时，它使用是否存在现有密码参数来指示该请求是来自管理员还是普通用户。换句话说，假设普通用户将始终提供现有的密码参数。

负责的代码如下所示：

String existingPassword = request.getParameter("existingPassword");
if (null == existingPassword)
{
trace("Old password not supplied, must be an administrator");
return true;
}
else
{
trace("Verifying user's old password");
...

2.3 攻击(The Attack)

当以这种方式明确地假设时，逻辑流变得明显。当然，普通用户可以发出不包含现有密码参数的请求，因为用户可以控制他们发出的请求的各个方面。

这种逻辑缺陷对应用程序来说是毁灭性的。它使攻击者可以重设任何其他用户的密码，并完全控制该用户的帐户.

HACK STEPS

1.在探查逻辑缺陷的关键功能时，请尝试依次删除请求中提交的每个参数，包括cookie，查询字符串字段和POST数据项。
2.确保删除参数的实际名称及其值。不要只提交一个空字符串，因为通常服务器会对此进行不同的处理。
3.一次仅攻击一个参数，以确保到达应用程序内的所有相关代码路径。
4.如果您要处理的请求是多阶段过程的一部分，请遵循该过程直至完成，因为某些后期逻辑可能会处理先前步骤中提供的并存储在会话中的数据。

3.示例3：继续结帐(Example 3: Proceeding to Checkout)

作者在在线零售商使用的Web应用程序中遇到了这种逻辑缺陷。

3.1 功能性(The Functionality)

下订单的过程涉及以下阶段：

1.浏览产品目录，然后将商品添加到购物篮。
2.返回购物篮，并完成订单。
3.输入付款信息。
4.输入交货信息。

3.2 假设(The Assumption)

开发人员认为用户将始终按预期顺序访问这些阶段，因为这是通过呈现给用户浏览器的导航链接和表格将这些阶段交付给用户的顺序。因此，完成订购过程的任何用户都必须沿途提交令人满意的付款细节。

3.3 攻击(The Attack)

由于相当明显的原因，开发人员的假设被拒绝了。用户控制了他们对应用程序提出的每个请求，因此可以按任何顺序访问订购过程的任何阶段。通过直接从第2阶段进入第4阶段，攻击者可以生成最终确定要交付的订单，但实际上尚未付款。

HACK STEPS
查找和利用此类漏洞的技术称为强制浏览。它涉及绕过浏览器内导航对可访问应用程序功能的顺序施加的任何控制：

1.当多阶段流程涉及已定义的请求顺序时，请尝试按预期顺序提交这些请求。尝试跳过某些阶段，不止一次访问一个阶段，然后再访问较早的阶段。
2.可以通过针对不同URL的一系列GET或POST请求来访问阶段序列，或者它们可能涉及向同一URL提交不同的参数集。可以通过在请求参数中提交函数名称或索引来指定所请求的阶段。确保完全了解应用程序用来提供对不同阶段的访问的机制。
3.从实现的功能的上下文中，尝试了解开发人员可能做出的假设以及关键攻击面所在的位置。尝试找出违反这些假设以在应用程序中引起不良行为的方式。
4.当不按顺序访问多级函数时，通常会在应用程序中遇到各种异常情况，例如具有空值或未初始化值的变量，部分定义或不一致的状态以及其他不可预测的行为。在这种情况下，应用程序可能会返回有趣的错误消息和调试输出，您可以使用它们更好地了解其内部工作原理，从而微调当前或不同的攻击（请参阅第15章）。有时，应用程序可能会进入开发人员完全无法预料的状态，这可能会导致严重的安全漏洞。

NOTE
本质上，许多类型的访问控制漏洞都与此逻辑流相似。当特权功能涉及通常按定义顺序访问的多个阶段时，应用程序可能会假定用户将始终按照该顺序进行该功能。应用程序可以在流程的初始阶段实施严格的访问控制，并且假设因此到达后期的任何用户都必须得到授权。如果低特权用户直接进入下一阶段，则她可以无限制地访问它。有关发现和利用这种漏洞的更多详细信息，请参见第8章。

Chapter 11 Attacking Application Logic(1)-The Nature of Logic Flaws
Chapter 11 Attacking Application Logic(2)-Real-World Logic Flaws(2)

Chapter 11 Attacking Application Logic(2)-Real-World Logic Flaws(1)

现实世界中的逻辑缺陷(1)