4.10.3-测试完整性检查

开启学习模式

已于 2024-10-18 14:55:07 修改

阅读量50

点赞数

分类专栏： 4.10 业务逻辑测试文章标签：数据库 web安全

于 2023-10-19 09:26:30 首次发布

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

版权

4.10 业务逻辑测试专栏收录该内容

12 篇文章 0 订阅

订阅专栏

本文探讨了在设计中依赖于用户角色的应用程序如何防范隐藏字段值被提交给服务器的风险，强调了服务器端的智能控制、业务逻辑检查和防止未经授权访问的重要性。举例说明了不同场景下的漏洞及测试方法，提出应用应遵循严格的访问控制和使用可信通道来保护数据完整性。

摘要由CSDN通过智能技术生成

测试完整性检查

ID
WSTG-BUSL-03

总结

许多应用程序旨在通过隐藏某些输入来根据用户或情况显示不同的字段。但是，在许多情况下，可以使用代理将隐藏字段值提交到服务器。在这些情况下，服务器端控件必须足够智能，以执行关系编辑或服务器端编辑，以确保根据用户和应用程序特定的业务逻辑允许服务器使用正确的数据。

此外，应用程序不得依赖不可编辑的控件、下拉菜单或隐藏字段进行业务逻辑处理，因为这些字段仅在浏览器的上下文中保持不可编辑状态。用户可能能够使用代理编辑器工具编辑其值，并尝试操作业务逻辑。如果应用程序将与业务规则（如数量等）相关的值公开为不可编辑的字段，则它必须在服务器端维护一个副本，并将其用于业务逻辑处理。最后，除了应用程序/系统数据之外，还必须保护日志系统以防止读取、写入和更新。

业务逻辑完整性检查漏洞的独特之处在于，这些误用案例是特定于应用程序的，如果用户能够进行更改，则应该只能根据业务流程逻辑在特定时间写入或更新/编辑特定工件。

应用程序必须足够智能，以检查关系编辑，并且不允许用户直接向服务器提交无效、受信任的服务器，因为它来自不可编辑的控件，或者用户无权通过前端提交。此外，必须“保护”日志等系统构件，防止未经授权的读取、写入和删除。

示例 1

假设有一个 ASP.NET GUI 应用程序，它只允许 admin 用户更改系统中其他用户的密码。管理员用户将看到用于输入用户名和密码的用户名和密码字段，而其他用户则不会看到这两个字段。但是，如果非管理员用户通过代理在用户名和密码字段中提交信息，他们可能会“欺骗”服务器相信请求来自管理员用户并更改其他用户的密码。

示例 2

大多数 Web 应用程序都有下拉列表，使用户可以轻松快速选择他们的状态、出生月份等。假设 Project Management 应用程序允许用户登录，并根据他们的权限向他们显示他们有权访问的项目下拉列表。如果攻击者找到他们不应该访问的另一个项目的名称并通过代理提交信息，会发生什么情况。应用程序是否会授予对项目的访问权限？即使他们跳过了授权业务逻辑检查，他们也不应该具有访问权限。

示例 3

假设机动车管理系统要求员工在签发身份证明或驾驶执照时首先验证每个公民的文件和信息。此时，业务流程已经创建了具有高度完整性的数据，因为员工会检查所提交数据的完整性。现在假设应用程序已移至 Internet，以便员工可以登录以获得完整服务，或者公民可以登录简化的自助服务应用程序以更新某些信息。此时，攻击者可能能够使用拦截代理来添加或更新他们不应访问的数据，并且他们可以通过声明公民未婚但提供配偶姓名的数据来破坏数据的完整性。这种类型的插入或更新未经验证的数据会破坏数据完整性，如果遵循业务流程逻辑，则可能会阻止这种行为。