在本节中，我们将学习设计和开发团队所犯的一些典型错误的示例，来查看是如何直接导致业务逻辑缺陷的，主要包含以下五个方面：
◆过度信任客户端控制
◆无法处理非常规输入
◆对用户行为做出有缺陷的假设
◆特定领域的缺陷
◆提供加密预言机
特定领域的缺陷
在许多情况下，会遇到特定业务领域或站点的逻辑缺陷。
在线商店的折扣功能是寻找逻辑缺陷时的典型攻击面，对于攻击者来说，这可能是一个潜在的金矿，在应用折扣的方式中会出现各种基本的逻辑缺陷。
例如，一个在线商店，它为超过1000元的订单提供10%的折扣，如果业务逻辑在应用折扣后无法检查订单是否已更改，那么这可能容易被滥用。在这种情况下，攻击者可以简单地把商品添加到他们的购物车中，直到它们达到1000元的门槛，然后在下订单之前移除他们不想要的商品。这样，即使订单不再满足预期标准，他们也会收到折扣。
应该特别注意那种标准价格调整或其他敏感值的情况，尝试了解应用程序使用什么算法来进行这些调整，以及在什么时候进行这些调整。这通常涉及操纵应用程序，使其在调整时处于不符合开发人员预期的原始标准状态。
要识别这些漏洞，需要仔细考虑攻击者可能拥有的目标，并尝试使用提供的功能找到实现此目标的不同方法。
这可能需要一定程度的特定领域知识，以便了解在给定的条件中哪些是有利的。
举个简单的例子，我们需要了解社交媒体，才能理解大量用户关注你的好处。
如果没有该领域的这种知识，可能会忽略危险行为，因为根本没有意识到其潜在的连锁反应。同样，我们可能很难将这些点连接起来，并注意到两个功能如何以有害的方式组合在一起。
场景试验-业务规则执行有缺陷：
https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-flawed-enforcement-of-business-rules
场景说明：
这个场景在购买工作流程中存在逻辑缺陷。
试验目的：
要完成这个试验，需要利用漏洞购买一件"Lightweight 133t leather jacket"。
攻击过程：
①登录后可以发现新用户有一张优惠券，代码：
NEWCUST5
②在页面底部，可以发现输入email订阅后会另外再给你张优惠券，代码：
SIGNUP30
③然后把那件商品添加到购物车里面，在折扣那一栏中分别填入两张优惠券的代码，尝试连续写入同一张优惠券代码会提示失败
④但当我们尝试轮流填入这两张优惠券代码时，发现可以反复使用，直至总金额到0，点击支付，完成本次试验
场景试验-无限金钱逻辑缺陷：
https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-infinite-money
场景说明：
这个场景在购买工作流程中存在逻辑缺陷。
试验目的：
要完成这个试验，需要利用漏洞购买一件"Lightweight 133t leather jacket"。
攻击过程：
①登录后先从最底部获取折扣券，然后我们用这个折扣券只需要花7元就可以额购买一张10元的礼品券
②购买礼品券后会有个劵码，在"My account"里面输入劵码会看到账户会增加10元，相当于每经过一轮这样的操作账户就可以多3元
③通过分析历史抓包，可以看出来主要分为5个步骤：
◆POST /cart：把礼品卡添加到购物车；
◆POST /cart/coupon：添加折扣券；
◆POST /cart/checkout：购买确认；
◆GET /cart/order-confirmation?order-confirmed=true：获取礼品卡的券码；
◆POST /gift-card：提交礼品券码兑换成购物款；
④接下来想办法自动化这个过程
◆打开"Project options">"Sessions"标签
◆在"Session handling rules"面板中，点击"Add"
◆在打开的面板中选择"Scope"标签，选择"Include all URLs"
◆选择"Details"标签，增加一个宏
◆在弹出的对话框中选择"Add"
⑤下面就是具体宏的制作了：
◆先按照第三部分中把五个步骤的请求包都选上，随后点击"OK"
◆选择获取礼品卡码的这个请求，点击"Configure item"，在弹出的对话框中再点击"Add"
◆取个名字，找到响应包中的礼品码，复选下，然后点击"OK"两次
◆选择兑换礼品码的请求进行配置
◆在变量抓取的位置，对"gift-card"变量选择从上一个响应包中抓取，点击"OK"
◆进行下测试，确保可以获取到礼品码并正常使用，多次点击"OK"
⑥接着配置自动攻击脚本：
◆把GET /my-account请求发送给Intruder，在"Positions"标签中清空所有变量
◆在"Payloads"标签中，选择类型选择"Null"，攻击次数设置为300次
◆在"Resource Pool"标签中设置最大每次1个请求，随后进行攻击
⑦可以发现，账户的金额在不断增大，当攻击结束后，用上打折券，就可以购买所需的商品了，完成本次试验。
试验小结：
通过这个试验，主要是了解如何自动配置宏，从响应包中抓取所需的数据放入到后一个请求包中去使用。
提供加密预言机
当用户的输入被加密后生成密文，随后以某种方式提供给用户时，可能会发生危险情况。
这种输入有时被称为“加密预言机”，攻击者可以利用此输入通过正确的算法和非对称密钥加密任意数据，然后将其传递给其他敏感函数。
如果站点上有另一个提供反向功能的用户可控输入，那么问题会变得更加复杂，攻击者能够解密其他数据以识别预期的结构，这就为他们创建恶意数据节省了工作。
加密预言机的严重性取决于哪些功能也使用与预言机相同的算法。
场景试验-通过加密预言机绕过身份验证：
https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-authentication-bypass-via-encryption-oracle
场景说明：
这个场景包含一个逻辑缺陷，该缺陷将加密预言机暴露给用户。
试验目的：
要完成这个试验，需要利用漏洞访问管理面板并删除carlos。
攻击过程：
①访问后登录时勾选"Stay logged in"，登录后尝试提交一篇评论，"email adress"这里输入个不规范的后提交，可以看到反馈页面会有条错误信息
②观察下两个包，把这两个包都发送到Repeater
◆POST /post/comment
◆GET /post?postID=X
可以发现前一个请求返回的红色框部分在第二个包中被放在cookie头中发送出去了，而红色框部分就是对填入的email地址采用了一种加密算法。我们可以简称第一个请求为“加密请求”，第二个请求为“解密请求”
③我们把"stay-logged-in"后面的加密参数替换掉“解密请求”红框部分，然后发送得到响应包
可以看到，这个维持登录的cookie也是采用了类似的加密算法，在把密文还原后，可以发现是"账号:时间串"组成的，把时间串复制出来。
④接下来我们要想办法获取"administrator:时间串"加密后的密文，用这个密文来作为维持登录的cookie
◆首先在“加密请求”中输入明文
◆将获得密文替换入“解密请求”来确认下实际的明文内容，可以发现，在我们原来的明文前面，系统自动增加了"Invalid email address: "这字符串一起加密
⑤要想办法要剥离这个字符串，数了下这个字符串是23位的（注意最后有个空格）
◆首先我们把前面获取到的密文发送到Decoder中
◆在Decoder中，分别用URL和Base64解码下编码格式
◆删除掉最后编码的前23位
◆再将剩余的编码反过来重新编译，并将最终结果复制出来
◆将复制出来编码替换到“解密请求”，但从响应包中发现有错误，要求密文是16的倍数
⑥错误的原因是我们删除了23位字符，导致剩下的密文不是16的倍数了，那我们给明文再凑9位字符上去，这样删除32位密文字符正好是16的倍数，那么剩下的也就是16的倍数了
◆重新构造下账户明文，添加9个字符
◆接下来继续按照第五大步里面，发送到Decoder进行解码后删除32位字符，再编码，将最终得到的字符串复制到“解密请求”中，可以得到正确的维持登录cookie所用的明文
⑦把Burp Proxy改成阻断模式，访问主页时把维持cookie替换成那个密文，发现有管理员登录权限了，能够在页面上看到管理面板，进入管理面板后删除carlos用户即可完成本试验
试验小结：
这个试验稍微有点复杂，主要利用的就是整个应用系统采用了同一套加密算法，并且可以同时获取到明文和密码让攻击者可以进行比对的漏洞。
命令注入攻击（上）
目录遍历攻击（上）
身份验证漏洞-多因素身份验证中的漏洞（上）
身份验证漏洞-基于密码的登录漏洞（上）
SQL注入攻击-检索隐藏的数据
HTTP高级请求走私-HTTP请求隧道（上）
HTTP高级请求走私-CRLF的利用（上）
HTTP高级请求走私-响应队列中毒
HTTP Host头漏洞-密码重置投毒
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：业务逻辑漏洞-利用示例（四）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论