完整性测试 (OTG-BUSLOGIC-003)

优质
小牛编辑
136浏览
2023-12-01

综述

许多应用程序被设计为通过部分隐藏输入表单来确定用户当前状态而展示不同的页面。但是,在许多情况下,有可能通过代理提交此类隐藏表单的值。在这些案例中,服务器端控制措施必须足够健壮来确保正确的业务逻辑数据。

此外,应用程序必须不依赖于不可编辑元素,下拉框列表或者业务逻辑处理过程的隐藏表单域,因为这些只是在浏览器的环境中不可编辑。用户可以使用代理工具来编辑这些参数并尝试操纵业务逻辑。如果应用程序对外暴露了业务规则数据如商品数量等作为不可编辑域,那么必须在服务器端存在同样的副本来共同作用在业务逻辑处理中。最后,作为应用程序/系统数据,日志系统必须足够安全来阻止读写更新操作。

业务逻辑完整性检查漏洞独特在相关的误用案例是应用程序相关的,如果用户可以改变某些功能,那么他们应该仅能在业务逻辑中的特定时刻进行写或者更新/编辑相关操作。

应用程序必须对编辑拥有足够的检查,不允许用户直接向服务器提交无效信息,不信任不可编辑域的信息或是未授权操作用户提交的信息。此外,系统关键组件如日志系统,应受到“保护”,不能被非授权读取、写入和移除。

测试案例

案例 1

想象一个ASP.NET应用只允许管理员用户来修改其他用户的密码。管理员用户能看到其他用户用户名和密码区域,而其他用户不能。但是,如果非管理员用户通过代理提交该该区域的用户名和密码,就有可能“欺骗”服务器来相信那些请求来自管理员用户,并为其他用户更改密码。

案例 2

大多数web应用使用下拉列表帮助用户进行快速选择状态、生日等等。假设一个项目管理应用允许用户登录,并将他们拥有权限的项目作为下拉框呈现。万一攻击者能找到没有权限的其他项目,并通过代理提交相关信息会如何?应用程序会通过访问请求么?他们不应该被允许,即使已经绕过了授权阶段的业务逻辑检查。

案例 3

假设摩托载具管理系统要求员工最初在市民申请标示或者驾驶许可证时验证每个市民资料和信息。在此时,业务处理过程创建了高级别数据完整性的数据,因为提交的数据被应用程序检查。现在假设应用程序移到了互联网之中,员工可以登录进行全业务服务,用户也可能登录进行自助服务来更新部分信息。此时,攻击者可以使用劫持代理来添加或更新他们没有权限进行控制的数据,并破坏数据完整性(比如给未婚市民提供配偶名字)。这种类型的插入/更新未确认的数据可能摧毁数据完整性,应该被阻止。

案例 4

许多系统包括用于审计和问题处理的日志系统。但是这些日志信息有多少是好的/有效的。他们能被攻击者有意无意改变来破坏完整性么?

如何测试

通用测试方法

  • 通览项目文档寻找应用程序组件(如输入域、数据库或日志)中移动、存储或处理数据/信息的部分。
  • 对于每一个这样的组件,确定那一部分的数据/信息是需要进行逻辑防护的。同时,考虑允许进行逻辑操作(插入、更新、删除)的角色情况。
  • 尝试在每个组件(输入、数据库、日志)中插入、更新、删除不合法的数据/信息。特别使用那些没有权限的用户进行操作。

特定测试方法 1

  • 使用代理捕获HTTP流量寻找隐藏域。
  • 如果发现隐藏域,弄清楚这些域的功能,使用代理提交不同的数据来尝试绕过业务处理流程,操纵这些无法控制的数值。

特定测试方法 2

  • 使用代理捕获HTTP流量寻找能够插入那些不可编辑区域的地方。
  • 一旦发现,弄清楚这些域的功能,使用代理提交不同数据进行比较,尝试绕过业务处理流程,控制这些不可编辑域的数据。

特定测试方法 3

  • 列举出可以进行编辑的应用程序组件,比如日志、数据库等。
  • 对于每一个识别出来的组件,尝试读取、修改或移除其中数据。比如识别出来的日志文件,测试人员应该试试操纵其收集的数据。

相关测试用例

所有 输入验证 相关的测试用例。

测试工具

ZAP是一个非常容易使用的web应用程序渗透测试整合工具。他被设计为符合不同安全经验的人员使用,特别是新接触渗透测试的开发人员和功能测试人员的理想工具。ZAP在提供一系列的用于手工漏洞检测的工具的同时也提供了自动化扫描器。

参考资料

整改措施

应用程序必须对编辑拥有足够的检查,不允许用户直接向服务器提交无效信息,不信任不可编辑域的信息或是未授权操作用户提交的信息。此外,任何可能被编辑修改的组件必须拥有对抗有意或无意的修改和升级措施。