业务逻辑攻击详解

攻击者并不总是通过破坏代码来窃取资金。

许多开发人员花费数月时间来保护 API 和加密。他们专注于防止 SQL 注入或 XSS。然而，攻击者可以在不破坏任何安全控制的情况下窃取资金。

这就是业务逻辑攻击。

应用程序完全按照设计运行。攻击者只是利用你自己的规则来对付你。

想想银行金库。大多数安全测试都会检查门是否坚固。而业务逻辑测试则会提出一个不同的问题：如果有人说服保安为他们开门呢？

金库没问题，但流程失效了。

以下是攻击者滥用银行逻辑的三种方式：

  1. 绕过等待期 银行通常要求在添加新收款人后等待 24 小时，以防止快速盗窃。攻击者可能会发现一个可以跳过此检查的 API 端点。他们绕过 UI 限制，瞬间转移资金。

  2. 突破交易限制 银行可能会设置 50,000 的每日限额。如果代码仅单独检查每笔交易，攻击者可以发送五笔 49,000 的转账。每笔交易看起来都是有效的。总额超过了限额，但系统却忽略了这一点。

  3. 奖励滥用 许多应用程序在支付账单时会提供返现。攻击者可能会支付账单然后立即取消。如果系统没有撤销奖励，攻击者就会通过循环来获取无尽的返现。

为什么自动化扫描器会漏掉这些？

扫描器寻找的是恶意软件或注入等技术缺陷。扫描器看到一笔成功的转账，并返回 200 OK 状态。它认为一切正常。

人工测试人员会问：这笔转账根本就不应该发生，对吗？

要发现这些缺陷，不要再问一个功能是否可以被黑客攻击（hacked），而要开始问一个功能是否可以被滥用（abused）。

检查以下领域：

  • 用户可以跳过验证步骤吗？
  • 用户可以更改 ID 的所有权吗？
  • 是否可以通过 API 绕过等待期？
  • 限额是针对总额强制执行的，还是仅针对单次点击？
  • 奖励是否可以被多次触发？

精锐的安全团队不仅仅创建用例（use cases）。他们还会创建滥用用例（abuse cases）。

与其测试“用户转账”，不如测试“攻击者尝试进行 500 次小额转账以绕过限额”。

第二个问题才能发现真正的风险。

来源：https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj