在本节中，我们将学习设计和开发团队所犯的一些典型错误的示例，来查看是如何直接导致业务逻辑缺陷的，主要包含以下五个方面：
◆过度信任客户端控制
◆无法处理非常规输入
◆对用户行为做出有缺陷的假设
◆特定领域的缺陷
◆提供加密预言机
过度信任客户端控制
一个有根本上缺陷的假设是用户只会通过提供的Web界面与应用程序交互，这点尤其危险，因为它会导致进一步假设客户端验证将阻止用户提供恶意输入。
但是，攻击者可以简单地使用Burp Proxy等工具在数据由浏览器发送之后未传递到服务器端之前对其进行篡改，这就使得客户端控件无效。
只接收提交的数据，而不执行适当的完整性检查和服务器端验证，可以让攻击者以相对最小的努力造成各种破坏。他们能够实现的确切目标取决于应用程序的功能以及对可控数据的作用。在某些情况下，这种缺陷可能会对与业务相关的功能和网站本身的安全性造成毁灭性的后果。
场景试验-过度信任客户端控制：
https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-excessive-trust-in-client-side-controls
场景说明：
这个场景没有充分验证用户输入，可以利用其采购工作流程中的逻辑缺陷以意想不到的价格购买商品。
试验目的：
要完成这个试验，需要购买"Lightweightl33t leather jacket"。
攻击过程：
①进去是个购物网站，需要购买的这个物品可以看到是第一项
②我们登录进去后，将这个物品添加到购物车中，然后去结算，发现买不了，因为我们的钱不够
③随后我们看下Burp Suite抓的包，发现其中有一条是添加购物车时候的请求，里面带了这个物品的金额，我们将这个请求发送到Repeater
④我们先把购物车清空掉，然后在Repeater中重新构造下这个包，把金额改小，随后发送这个请求
⑤接着刷新下购物车，可以看到购物车内这个物品的金额变了
⑥成功支付后，完成这个试验
场景小结：
当然，在现实中不会存在这样的逻辑漏洞，只是通过这个试验场景，来了解下如果完全信任客户端所提交的数据，会产生怎么样的后果。因此通常都会要求在服务器端进行数据校验来避免这样的漏洞被利用。
另一个跟这种属于同样类型的业务逻辑缺陷的试验场景，以前在双因素身份验证中做过，可以直接通过传输门去看一下：
无法处理非常规输入
应用程序逻辑的目的之一是将用户输入限制为符合业务规则的值。例如，应用程序可能被设计为接受某种数据类型的任意值，但从业务的角度来看，逻辑决定了这个值是否可以接受。许多应用程序将数字限制纳入其逻辑，这可能包括管理库存、应用预算限制、触发供应链阶段等。
我们以在线商店来示例，在订购产品时，用户通常会指定他们想要订购的数量，尽管理论上任何整数都是有效的输入，但业务逻辑可能会阻止用户订购比当前库存更多的单位。
为了实现这样的规则，开发人员需要预测所有可能的场景，并将处理它们的方法正和岛应用程序逻辑中。换句话说，它们需要告诉应用程序它是否应该允许给定的输入，以及它应该如何根据各种条件做出反映。如果没有明确的逻辑来处理给定的情况，这个能会导致意外和潜在的可利用行为。
例如，数字类型数据可能接收负值，根据相关功能，业务逻辑允许这样做可能没有意义。但是，如果应用程序没有执行足够的服务器端验证并拒绝这个输入，那么攻击者可能会传入负值并引发其他某些行为。
考虑两个银行账户之间的资金转移，这个功能几乎肯定会在完成转账之前检查发件人是否有足够的资金：
但是，如果这个逻辑不能阻止用户在金额参数中输入复制，那么攻击者可能会利用这一点绕过余额检查并将资金转移到“错误”的方向。比如攻击者将-1000元发送到受害者的账户，这可能会导致他们从受害者那里收到1000元，因为逻辑始终认为-1000元小于当前余额并批准转移。
如果它们主线在正确的功能中，像这样简单的逻辑缺陷可能是毁灭性的。在开发和测试过程中很容易错过他们，尤其是考虑到此类输入可能会被Web界面上的客户端口控件阻止。
在测试应用程序时，我们可以使用BurpProxy和Repeater等工具来尝试提交非常规值，尤其是尝试在合法用户不太可能输入的范围内输入。这包括异常高或异常低的数字以及基于文本字段的异常长字符串，我们甚至可以尝试其他数据类型。
通过观察应用程序的响应，我们应该尝试回答以下问题：
●是否对数据施加了任何限制？
●当达到这些限制时会发生什么？
●输入是否正在执行任何转换或规范化？
这些可能会暴露弱输入验证，从而允许我们以不寻常的方式操作应用程序。如果在目标网站上发现一个表单无法安全地处理非常规输入，那么其他表单很可能会遇到同样的问题。
场景试验-无法处理非常规输入一：
https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-high-level
场景说明：
这个场景没有充分验证用户输入，可以利用其采购工作流程中的逻辑缺陷以意想不到的价格购买商品。
试验目的：
要完成这个试验，需要购买"Lightweightl33t leather jacket"。
攻击过程：
①跟上面的那个试验一样，同样的购物网站，抓包后发现价格不是从客户端发出去了，但是数量还是从客户端发送的，把添加购物车的请求发送到Repeater，Repeater重新修改个负数后发送，刷新下购物车，可以看到会显示产品数量为负数
②接下来我们把需要买那个产品购物数量为1，然后随便找个其他商品不停添加负数到购物车，直到总金额小于100
③再点击购买，可以看到购买成功了，完成本试验
命令注入攻击（上）
目录遍历攻击（上）
身份验证漏洞-多因素身份验证中的漏洞（上）
身份验证漏洞-基于密码的登录漏洞（上）
SQL注入攻击-检索隐藏的数据
HTTP高级请求走私-HTTP请求隧道（上）
HTTP高级请求走私-CRLF的利用（上）
HTTP高级请求走私-响应队列中毒
HTTP Host头漏洞-密码重置投毒
HTTP Host头漏洞攻击-概念梳理
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论