4.10.1-测试业务逻辑数据验证_数据字段逻辑测试-CSDN博客

本文链接：https://blog.csdn.net/qq_44232452/article/details/133919558

测试业务逻辑数据验证

ID
WSTG-BUSL-01

总结

应用程序必须确保只有逻辑上有效的数据才能在前端输入，以及直接输入到应用程序或系统的服务器端。仅在客户端/前端验证数据可能会使应用程序容易受到通过代理或与其他系统交接的服务器注入的影响。这与简单地执行边界值分析（BVA）不同，因为它更困难，并且在大多数情况下不能在入口点进行简单验证，而通常需要检查其他系统。

例如：应用程序可能会要求您提供社会安全号码。在 BVA 中，应用程序应该检查输入的数据的格式和语义（值是 9 位数字长，不是负数，也不是全是 0），但也有一些逻辑注意事项。SSN 被分组和分类。这个人在死亡档案上吗？他们来自该国的某个地区吗？

与业务数据验证相关的漏洞是独一无二的，因为它们是特定于应用程序的，与伪造请求相关的漏洞不同，它们更关心逻辑数据，而不是简单地破坏业务逻辑工作流。

应用程序的前端和后端应该验证和确认它拥有、正在使用和传递的数据在逻辑上是有效的。即使用户向应用程序提供了有效数据，业务逻辑也可能使应用程序的行为因数据或情况而异。

示例 1

假设您管理着一个允许用户订购地毯的多层电子商务网站。用户选择他们的地毯，输入尺寸，进行付款，前端应用程序已验证所有输入的信息对于地毯的联系信息、尺寸、品牌和颜色都是正确和有效的。但是，后台的业务逻辑有两条路径，如果地毯有库存，则直接从您的仓库发货，但如果您的仓库缺货，则会调用合作伙伴的系统，如果他们有库存，他们将从他们的仓库发货并由他们退款。如果攻击者能够继续进行有效的现货交易并将其作为缺货发送给您的合作伙伴，会发生什么情况？如果攻击者能够进入中间，并在不付款的情况下向合作伙伴仓库订购地毯发送消息，会发生什么情况？

示例 2

许多信用卡系统现在每晚都会下载账户余额，以便客户可以更快地查看低于特定价值的金额。反之亦然。如果我在早上还清了我的信用卡，我可能无法在晚上使用可用的信用额度。另一个例子是，如果我在多个位置非常快速地使用我的信用卡，并且系统根据昨晚的数据做出决策，则可能会超过我的限额。

示例 3

Distributed Denial of Dollar (DDo$):
这是由“The Pirate Bay”网站的创始人发起的一项活动，针对对“The Pirate Bay”提起诉讼的律师事务所。目标是利用业务功能设计和信用转移验证过程中的错误。

此次攻击是通过向律师事务所发送 1 瑞典克朗（0.13 美元）的非常少量的资金来执行的。
付款的银行账户只有 1000 次免费转账，之后任何转账都会向账户持有人收取附加费（2 瑞典克朗）。在前 1000 笔互联网交易之后，每向律师事务所捐赠 1 瑞典克朗，实际上最终会花费 1 瑞典克朗。

测试目标

确定数据注入点。
验证所有检查是否都在后端进行，并且无法绕过。
尝试打破预期数据的格式并分析应用程序如何处理它。

如何测试

通用测试方法

查看项目文档并使用探索性测试来查找数据入口点或系统或软件之间的交接点。
找到后，尝试将逻辑上无效的数据插入应用程序/系统。
具体检测方法：
在应用程序上执行前端 GUI 功能有效性测试，以确保仅接受“有效”值。
使用拦截代理，观察 HTTP POST/GET 查找传递 cost 和 quality 等变量的位置。具体来说，在应用程序/系统之间寻找可能是注入点或篡改点的“交接”。
找到变量后，开始使用逻辑上“无效”的数据（例如不存在或不符合业务逻辑的社会保险号或唯一标识符）询问字段。此测试将验证服务器是否正常运行，并且不接受逻辑上无效的数据。