参考:The Web Application Hackers Handbook Chapter 11

1. 示例7：大量折扣作弊(Example 7: Cheating on Bulk Discounts)

作者在软件供应商的零售应用程序中遇到了此逻辑缺陷。

1.1 功能性(The Functionality)

该应用程序允许用户订购软件产品，并在购买了合适的商品捆绑包时有资格获得批量折扣。例如，购买防病毒解决方案，个人防火墙和反垃圾邮件软件的用户有权享受个人价格25％的折扣。

1.2 假设(The Assumption)

当用户向其购物篮中添加软件项目时，该应用程序将使用各种规则来确定他选择了他的购买商品是否有折扣。如果是这样，购物篮中相关项目的价格将根据折扣进行调整。开发人员假定用户将继续购买所选的捆绑包，因此有权获得折扣。

1.3 攻击(The Attack)

开发人员的假设显然是虚假的，因为它忽略了用户在添加商品后可能会从购物篮中删除商品这一事实。狡猾的用户可以将卖主出售的每种产品的数量增加到他的购物篮中，以吸引最大的批量折扣。在将折扣应用到他的购物篮中的物品之后，他可以删除他不想要的物品，并仍然获得适用于其余产品的折扣。

HACK STEPS

1. 在根据用户可控制的数据或操作确定的标准调整价格或其他敏感值的任何情况下，首先要了解应用程序使用的算法以及其逻辑内进行调整的点。确定这些调整是一次性进行的，还是根据用户执行的进一步操作进行了修订。
1. 想像一下。尝试找到一种方法来操纵应用程序的行为，以使其进入一种状态，即该应用程序进行的调整不符合其设计者预期的原始标准。如上所述，在最明显的情况下，这可能仅涉及在应用折扣后从购物车中删除商品！

2. 示例8：逃避转义(Example 8: Escaping from Escaping)

作者在各种Web应用程序中都遇到了这种逻辑缺陷，包括网络入侵检测产品使用的Web管理界面。

2.1 功能性(The Functionality)

该应用程序的设计者已决定实现一些功能，其中涉及将用户可控制的输入作为操作系统命令的参数传递。应用程序的开发人员了解这种操作涉及的固有风险（请参阅第9章），并决定对此进行防御。清理用户输入中的任何潜在恶意字符会带来风险。以下任何实例将使用反斜杠字符进行转义：

; | & < > ' space and newline

以这种方式转义数据会使Shell命令解释器将相关字符视为传递给调用命令的参数的一部分，而不是视为Shell元字符。此类元字符可用于注入其他命令或参数，重定向输出等。

2.2 假设(The Assumption)

开发人员确信他们已经针对命令注入攻击设计了强大的防御措施。他们集思广益地设计了可能有助于攻击者的所有可能角色，并确保他们全部逃脱并因此安全。

2.3 攻击(The Attack)

开发人员忘记了转义字符本身。

当利用简单的命令注入流时，反斜杠字符通常不直接用于攻击者。因此，开发人员并未将其识别为潜在恶意软件。但是，由于无法逃脱，他们为攻击者提供了一种手段来击败其消毒机制。假设攻击者向易受攻击的功能提供了以下输入：

foo\;ls

如前所述，该应用程序应用了相关的转义，因此攻击者的输入变为：

foo\\;ls

当将此数据作为参数传递给操作系统命令时，shell解释器将第一个反斜杠视为转义字符。因此，它将第二个反斜杠视为文字反斜杠，而不是转义字符，而是作为参数本身的一部分。然后遇到一个显然无法逃脱的分号。它将其视为命令分隔符，因此继续执行攻击者提供的注入命令。

HACK STEPS
每当您尝试将命令元数据和其他错误插入应用程序时，试图将相关的元字符插入到您控制的数据中，请始终尝试在每个此类字符之前放置一个反斜杠以测试上述逻辑错误。

NOTE
在针对跨站点脚本攻击的一些防御措施中也可以找到同样的缺点（请参阅第12章）。当用户提供的输入直接复制到一段JavaScript中的字符串变量的值中时，该值将封装在引号中。为了保护自己免受跨站点脚本攻击，许多应用程序使用反斜杠来转义用户输入中出现的所有引号。但是，如果不对反斜杠字符本身进行转义，则攻击者可以提交\'以打破字符串，从而控制脚本。在Ruby On Rails框架的早期版本的escape_javascript函数中发现了此确切的错误。

3. 示例9：使输入验证无效(Example 9: Invalidating Input Validation)

作者在电子商务站点中使用的Web应用程序中遇到了这种逻辑缺陷。可以在许多其他应用程序中找到变体。

3.1 功能性(The Functionality)

该应用程序包含一套输入验证例程，以防止各种类型的攻击。这些防御机制中的两个是SQL注入过滤器和长度限制器。

应用程序通常尝试通过转义基于字符串的用户输入中出现的任何单引号（并拒绝出现在数字输入中的任何引号）来尝试防御SQL注入。如第9章所述，两个单引号一起是一个转义序列，代表一个文字单引号，数据库将其解释为带引号的字符串（而不是结束字符串的终止符）中的数据。因此，许多开发人员认为，通过将用户提供的输入中的任何单引号加倍，他们将防止发生任何SQL注入攻击。

长度限制器应用于所有输入，确保用户提供的变量不超过128个字符。它通过将所有变量截断为128个字符来实现此目的。

3.2 假设(The Assumption)

从安全的角度出发，假定SQL注入过滤器和长度截断都是理想的防御措施，因此应同时使用。

3.3 攻击(The Attack)

SQL注入防御通过将用户输入中出现的所有引号加倍来起作用，以便在每对引号中，第一个引号充当第二个引号的转义字符。但是，开发人员没有考虑如果将清理后的输入交给截断函数会发生什么情况。

回想一下第9章中登录函数中的SQL注入示例。假设应用程序将用户输入中包含的任何单引号都加倍，然后对数据施加长度限制，将其截断为128个字符。提供此用户名：

admin'--

现在导致以下查询，该查询无法绕过登录：

SELECT * FROM users WHERE username = 'admin''--' and password = ''

但是，如果您提交以下用户名（包含127个后跟一个引号），则：

aaaaaaaa[...]aaaaaaaaaaa'

应用程序首先将单引号加倍，然后将字符串截断为128个字符，从而将输入返回到其原始值。这将导致数据库错误，因为您在查询中注入了附加的单引号而不固定周围的语法。如果现在还提供密码：

or 1=1--

应用程序执行以下查询，该查询成功绕过了登录：

SELECT * FROM users WHERE username = 'aaaaaaaa[...]aaaaaaaaaaa'' and
password = 'or 1=1--'v

a的字符串末尾的双引号被解释为转义的引号，因此，被解释为查询数据的一部分。该字符串有效地一直延伸到下一个单引号，该单引号在原始查询中标记了用户提供的密码值的开始。因此，数据库可以理解的实际用户名是此处显示的文字字符串数据：

aaaaaaaa[...]aaaaaaaaaaa'and password =

因此，接下来发生的任何事情都将解释为查询本身的一部分，并且可以精心设计以干扰查询逻辑。

TIP
您可以通过依次提交两个以下格式的长字符串来测试这种类型的漏洞，而无需确切知道要施加的长度限制：

'''''''''''''''''''''''''''''''''''''''' and so on
a''''''''''''''''''''''''''''''''''''''' and so on

并确定是否发生错误。转义输入的任何截断都将在偶数或奇数个字符之后发生。无论哪种情况，前面的字符串之一都会导致在查询中插入奇数个单引号，从而导致语法无效。

HACK STEPS
记下应用程序修改用户输入的任何实例，特别是通过截断，剥离数据，编码或解码的方式。对于任何观察到的实例，请确定是否可以设计恶意字符串：

1. 如果数据被剥离一次（非递归），请确定是否可以提交补偿此字符串的字符串。例如，如果应用程序过滤SQL关键字（例如SELECT），则提交SELSELECTECT并查看生成的过滤是否删除了内部SELECT子字符串，并保留单词SELECT。
1. 如果数据验证按设定顺序进行，并且一个或多个验证过程修改了数据，请确定是否可以将其用于击败先前的验证步骤之一。例如，如果应用程序执行URL解码，然后剥离诸如<script>标记之类的恶意数据，则可以使用以下字符串来克服此问题：
```
%<script>3cscript%<script>3ealert(1)%<script>3c/
script%<script>3e
```

NOTE
跨站点脚本过滤器经常不建议删除HTML标记对之间出现的所有数据，例如<tag1> aaaaa </tag1>。这些通常容易受到此类攻击。

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

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

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