参考:The Web Application Hackers Handbook Chapter 11
1. 示例10：滥用搜索功能(Example 10: Abusing a Search Function)
作者在提供基于订阅的金融新闻和信息访问的应用程序中遇到了这种逻辑缺陷。 后来，在两个完全不相关的应用程序中发现了同一漏洞，说明了许多逻辑漏洞的微妙和普遍性。
1.1 功能性(The Functionality)
该应用程序提供对历史和当前信息的巨大存档的访问，这些历史和当前信息包括公司报告和帐户，新闻稿，市场分析等。 这些信息大多数仅付费用户可以访问。
该应用程序提供了功能强大且细粒度的搜索功能，所有用户都可以访问。 当匿名用户执行查询时，搜索功能将返回指向与查询匹配的所有文档的链接。 但是，要求用户订阅以检索其查询返回的任何实际受保护文档。 应用程序的所有者将这种行为视为一种有用的营销策略。
1.2 假设(The Assumption)
该应用程序的设计师认为，用户如果不付费就无法使用搜索功能来提取任何有用的信息。 搜索结果中列出的文档标题通常是含糊不清的，例如” 2010年度结果”，”新闻稿08-03-2011”等等。
1.3 攻击(The Attack)
因为搜索功能指示了与给定查询匹配的文档数量，所以有经验的用户可能会发出大量查询，并使用推断从搜索功能中提取通常需要付费的信息。 例如，以下查询可用于将单个受保护文档的内容归零：
wahh consulting
>> 276 matches
wahh consulting "Press Release 08-03-2011" merger
>> 0 matches
wahh consulting "Press Release 08-03-2011" share issue
>> 0 matches
wahh consulting "Press Release 08-03-2011" dividend
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover
>> 1 match
wahh consulting "Press Release 08-03-2011" takeover haxors inc
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover uberleet ltd
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover script kiddy corp
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover ngs
>> 1 match
wahh consulting "Press Release 08-03-2011" takeover ngs announced
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover ngs cancelled
>> 0 matches
wahh consulting "Press Release 08-03-2011" takeover ngs completed
>> 1 match
尽管用户无法通过充分的想象力和脚本请求的使用来查看文档本身，但他仍可以对文档的内容建立相当准确的理解。
TIP
在某些情况下，以这种方式能够通过搜索功能浸出信息对于应用程序本身的安全至关重要，它有效地公开了管理功能，密码和使用中的技术的详细信息。
TIP
事实证明，该技术是对内部文档管理软件的有效攻击。 作者已使用此技术从存储在Wiki中的配置文件中强行破解密钥密码。 因为如果搜索字符串出现在页面中的任何位置（而不是整个单词匹配），Wiki都会返回命中信息，因此可以逐个字母地强行输入密码，搜索以下内容：
Password=A
Password=B
Password=BA
...
2. 示例11：捕获调试消息(Example 11: Snarfing Debug Messages)
作者在金融服务公司使用的Web应用程序中遇到了这种逻辑缺陷。
2.1 功能性(The Functionality)
该应用程序是最近才部署的。 像许多新软件一样，它仍然包含许多与功能有关的错误。 间歇地，各种操作将以无法预测的方式失败，并且用户将收到错误消息。
为了便于调查错误，开发人员决定在这些消息中包括详细的详细信息，其中包括以下详细信息：
- 用户的身份
- 当前会话的令牌
- 被访问的URL
- 产生错误的请求所附带的所有参数
当服务台人员试图调查系统故障并从系统故障中恢复时，生成这些消息非常有用。 他们还帮助解决了其余的功能错误。
2.2 假设(The Assumption)
尽管安全顾问通常警告说，攻击者可能会滥用这种冗长的调试消息，但开发人员仍认为他们没有打开任何安全漏洞。 用户可以通过检查浏览器处理的请求和响应来轻松获得调试消息中包含的所有信息。 该消息没有包含有关实际故障的任何详细信息，例如堆栈跟踪，因此可以想象，它们对于制定针对应用程序的攻击没有帮助。
2.3 攻击(The Attack)
尽管开发人员对调试消息的内容有所了解，但是由于他们在实现调试消息的创建过程中犯了错误，因此开发人员的假设存在缺陷。
发生错误时，应用程序的组件将收集所有必需的信息并进行存储。 向用户发出了HTTP重定向，该URL重定向到显示此存储信息的URL。 问题在于应用程序的调试信息存储以及用户对错误消息的访问不是基于会话的。 而是，调试信息存储在静态容器中，并且错误消息URL始终显示最后放置在该容器中的信息。 开发人员已经假定，跟随重定向的用户将仅看到与他们的错误有关的调试信息。
实际上，在这种情况下，由于两个错误几乎同时发生，因此有时会向普通用户显示与其他用户的错误有关的调试信息。 但是，除了有关线程安全性的问题（请参见下一个示例）之外，这还不只是竞争条件。 发现错误机制的功能的攻击者可以简单地反复轮询消息URL，并在每次更改时记录结果。 在数小时的时间内，此日志将包含有关众多应用程序用户的敏感数据：
- 一组可以用于密码猜测攻击的用户名
- 一组会话令牌，可用于劫持会话
- 一组用户提供的输入，其中可能包含密码和其他敏感物品
因此，错误机制带来了严重的安全威胁。 由于管理用户有时会收到这些详细的错误消息，因此监视错误消息的攻击者很快就会获得足够的信息，以破坏整个应用程序。
HACK STEPS
-
- 要检测此类缺陷，请首先对所有可能生成的异常事件和条件进行分类，其中涉及异常有趣的用户特定信息，这些信息会以异常方式（例如调试错误消息）返回给浏览器。
-
- 将应用程序并行用作两个用户，使用一个或两个用户系统地设计每个条件，并确定每种情况下其他用户是否都受到影响。
3. 示例12：争夺登录(Example 12: Racing Against the Login)
最近，这种逻辑缺陷影响了几个主要应用程序。
3.1 功能性(The Functionality)
该应用程序实现了一个健壮的，多阶段的登录过程，其中要求用户提供几个不同的凭据才能获得访问权限。
3.2 假设(The Assumption)
身份验证机制已经过许多设计审查和渗透测试。 所有者确信没有可行的手段来攻击该机制以获得未经授权的访问。
3.3 攻击(The Attack)
实际上，身份验证机制包含一个细微的缺陷。 有时，当客户登录时，他可以访问一个完全不同的用户的帐户，从而使他能够查看该用户的所有财务详细信息，甚至可以从其他用户的帐户进行付款。 该应用程序的行为最初看起来是随机的：用户没有执行任何异常操作来获得未经授权的访问，并且随后的登录也没有再次出现异常。
经过一番调查，银行发现当两个不同的用户恰好同时登录该应用程序时，便发生了错误。 它并没有在所有这种情况下发生，仅在其中一部分情况下发生。 根本原因是应用程序短暂地将关于每个新认证用户的密钥标识存储在静态（非会话）变量中。 写入后，此变量的值会在稍后读取。 如果在此瞬间已将另一个线程（处理另一个登录名）写入变量，则较早的用户将进入属于后续用户的经过身份验证的会话。
该漏洞源于与前面描述的错误消息示例中相同的类型的错误：应用程序使用静态存储来保存应该基于每个线程或每个会话存储的信息。 但是，由于无法可靠地复制本示例，因此它的检测要困难得多，并且很难利用。
这种缺陷被称为”竞赛条件”，因为它们涉及在特定情况下在短时间内出现的漏洞。 由于该漏洞仅存在很短时间，因此攻击者在应用程序再次将其关闭之前”竞相”利用它。 在攻击者位于应用程序本地的情况下，通常可以设计出出现竞争状况的确切情况，并在可用窗口内可靠地利用漏洞。 在攻击者远离应用程序的地方，这通常很难实现。
可以理解，了解此漏洞本质的远程攻击者可以通过使用脚本连续登录并检查所访问帐户的详细信息，设计出一种利用此漏洞的攻击。 但是，可以利用此漏洞的小窗口意味着需要大量请求。
在正常的渗透测试中未发现竞争条件也就不足为奇了。 只有当应用程序获得了足够多的用户基础以发生随机异常时，出现这种情况的条件才出现，这些异常由客户报告。 但是，对身份验证和会话管理逻辑进行仔细的代码审查可能会发现问题。
HACK STEPS
针对此类细微的线程安全问题执行远程黑盒测试并非易事。 它应该被视为一项专门的工作，可能仅在对安全性要求最高的应用程序中才有必要。
-
- 以关键功能的选定项目为目标，例如登录机制，密码更改功能和资金转帐过程。
-
- 对于测试的每个功能，请确定给定用户可以用来执行单个操作的单个请求或少量请求。 还可以找到确认操作结果的最简单方法，例如，验证给定用户的登录是否可以访问该人的帐户信息。
-
- 使用几台高规格机器，从不同的网络位置访问该应用程序，编写攻击脚本以代表多个不同的用户重复执行相同的操作。 确认每个动作是否具有预期的结果。
-
- 为大量误报做好准备。 根据应用程序支持基础架构的规模，此活动很可能构成对安装的负载测试。 可能由于与安全无关的原因而经历异常。
Chapter 11 Attacking Application Logic(2)-Real-World Logic Flaws(3)
Chapter 11 Attacking Application Logic(3)-Avoiding Logic Flaws
