4.3.1- 测试角色定义

测试角色定义

ID
WSTG-IDNT-01

总结

应用程序具有多种类型的功能和服务，这些功能和服务需要根据用户的需求获得访问权限。该用户可能是：

• 管理员，用于管理应用程序功能。
• 审计师，他们审查应用程序交易并提供详细报告。
• 支持工程师，他们帮助客户调试和修复其帐户上的问题。
• 客户，他们与应用程序交互并从其服务中受益。

为了处理这些用途以及该应用程序的任何其他用例，需要设置角色定义（通常称为 RBAC）。基于这些角色，用户能够完成所需的任务。

测试目标

• 识别并记录应用程序使用的角色。
• 尝试切换、更改或访问其他角色。
• 查看角色的粒度以及所授予权限背后的需求。

如何测试

角色识别

测试人员应首先通过以下任一方法确定要测试的应用程序角色：

• 应用文档。

• 由应用程序的开发人员或管理员提供指导。

• 应用程序注释。

• 模糊可能的角色：

  • cookie 变量(例 role=admin, isAdmin=True)
  • 帐户变量 (例 Role: manager)
  • 隐藏目录或文件(例 /admin, /mod, /backups)
  • 切换到知名用户(例 admin, backups, etc.)

切换到可用角色

在确定可能的攻击媒介后，测试人员需要测试并验证他们是否可以访问可用角色。

某些应用程序在创建时通过严格的检查和策略，或者通过后端创建的签名确保用户的角色得到适当保护来定义用户的角色。发现角色存在并不意味着它们是一个漏洞。

查看角色权限

在获得对系统上角色的访问权限后，测试人员必须了解提供给每个角色的权限。

支持工程师不应能够代替用户执行管理功能、管理备份或执行任何事务。

管理员不应对系统拥有完全权限。敏感的管理功能应利用 maker-checker 原则，或使用 MFA 来确保管理员正在执行事务。一个明显的例子是 2020 年的 Twitter 事件.。

Tools

上述测试可以在不使用任何工具的情况下进行，但用于访问系统的工具除外。

为了使事情变得更容易和更有条理，可以使用：

• Burp’s Autorize extension
• ZAP’s Access Control Testing add-on

引用

• Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007
• Role engineering and RBAC standards