要求 ID

工作组反馈

8.1.6

会将此要求重新视为更可行的做法（例如，备份仅应保留 X 次，应监控备份是否存在盗窃/损坏，应定期审核备份以确认其恢复到生产环境）。目前的假设过于宽泛，需要更多定义。

5.1.4

与其他测试用例重复。这是一个高价值、低价值的测试用例。建议移除。

7.3.3

与其他测试用例重复。这是一个高价值、低价值的测试用例。建议移除。

1.2.2

由于其他要求（例如 4.1.1）中的覆盖范围而被移除

2.2.4

移除了 Req，因为它在 4.3.1 的涵盖范围内

（4.3.1 验证管理接口是否使用适当的多重身份验证来

防止未经授权的使用。）涵盖可在管理界面和其他内部访问路径中防范钓鱼式攻击的内容

2.2.5

移除，因为大多数 CSP 都不支持 mTLS，而且针对 CASA 进行测试的大多数开发者都将使用基于密码的身份验证

2.4.3

书面标准不够具体，无法强制执行

2.4.5

ASVS V5 中已移除的要求以及 2.4.1 中建议的哈希算法无法满足此要求

2.7.5

该测试可能需要对第三方 OOB 提供商进行分析，因此不可行。由于身份验证代码的生命周期很短，因此此处的风险很低。

2.8.2

要求仅与自定义 MFA 解决方案相关，也受 6.4.2 和 6.4.1 的约束

2.8.5

移除要求（因为它在 2.7.6 的涵盖范围内），此外，尝试失败的尝试也受 ASVS 的日志记录要求的约束

2.8.6

应用级别的物理动态密码不是常见的用例，管理员需要此频率要求。但是要求 4.3.1 版（验证管理界面使用适当的多重身份验证以防止未经授权的使用。）涵盖管理界面的 MFA，将涵盖此风险

2.9.1

此要求适用于根据 ASVS 定义的实体设备（加密安全密钥是智能卡或 FIDO 密钥，用户必须插入或配对

完成设备身份验证。 验证程序向 Google 的

加密设备或软件，并且设备或软件根据

。{/1}

2.9.3 版

此要求适用于根据 ASVS 定义的实体设备（加密安全密钥是智能卡或 FIDO 密钥，用户必须插入或配对

完成设备身份验证。 验证程序向 Google 的

加密设备或软件，并且设备或软件根据

。{/1}

2.10.1

要求与 2.10.2 相矛盾

2.10.3

适用于 2.4.1（验证在为应用存储用户的密码时，是否使用了以下密码哈希函数之一：argon2id、scrypt、bcrypt 或 PBKDF2），这些函数会存在离线攻击和密码存储的风险。

2.10.4

在 6.4.2 的涵盖范围内。请验证密钥材料是否未暴露给应用，而是使用独立的安全模块（例如保险柜）进行加密操作。

3.2.3

在 3.4.1、3.4.2 和 3.4.3 的范围内

3.5.1

用户可以通过 OAuth 提供方撤消令牌

4.3.3

对于管理员界面和特许访问权限，要求由 MFA 涵盖

5.1.3

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

5.1.4

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

5.3.2

要求所有 Unicode 字符均有效这一要求可能会使测试变得困难。并非所有应用都包含足够大的文本文本，能够容纳每个 Unicode 字符。此外，整个 Unicode 空间还缺少对某些操作系统和黑客工具的支持，因此，即使服务器支持，您也无法对此进行测试。整体的安全性值有问题。最初包含在 Beta 版中，但由于测试出现问题而被移除。

6.2.5 版

在 6.2.4 和 6.2.3 的范围内

6.2.6 版

在 6.2.4 和 6.2.3 的范围内

6.3.1

在 6.2.4 和 6.2.3 的范围内

6.3.3

。

7.1.2

7.1.1 支持

7.1.3

7.1.1 支持

7.3.1

7.1.1 支持

7.3.3

7.1.1 支持

8.1.3

很难描述什么是可接受或必需的参数。并非可测试的情况。哪些要素是必要的？如何确定异常是否有效？ 被视为不在 CASA 中

8.3.3

这不是一项可测试的要求，与隐私权政策和服务条款（而不是应用安全性）相关。这是法律和合规性审核，不在 CASA 的范围内

8.3.6

控件是系统特定的（Windows/Linux 变体）和设备专用，在大多数情况下不属于应用控件。

8.3.8

在 1.8.1、1.8.2 和 1.1.4 的涵盖范围内

9.2.5 版

第 8.3.5 节

10.1.1

涵盖架构审核，是推荐采用的最佳做法。要求不可测试

10.2.3

在合理的时间内无法做到。任何奇怪的代码都应予以记录和审核，不过，设置特定任务以确保不存在后门程序需要逐行深入审核代码，也不能保证后门程序不存在。

难以测试设计良好的恶意函数

10.2.4

无法进行测试。无法在合理的时间内完成。任何奇怪的代码都应予以记录和审核，不过，通过设置具体任务来确保没有后门程序这一功能，需要逐行深入审核代码，也不能保证后门程序不存在。

难以测试设计良好的恶意函数

10.2.5

无法进行测试。无法在合理的时间内完成。任何奇怪的代码都应予以记录和审核，不过，通过设置具体任务来确保没有后门程序这一功能，需要逐行深入审核代码，也不能保证后门程序不存在。

难以测试设计良好的恶意函数

13.1.1

在 5.2.6 和 5.3.9 的范围内

12.3.1

存在 ASVS 和 CASA 第 5 章（验证、排错和编码）中其他现有要求所涵盖的路径遍历风险

12.3.3

在 5.2.6 和 5.3.9 的范围内

12.3.6

在 10.3.2 12.4.1 和 12.4.2 的范围内

12.5.1

在 10.3.2 和 12.4.2 的范围内

12.5.2

在 10.3.2 12.4.1 和 12.4.2 的范围内

13.1.5

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

13.2.2

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

13.2.3

涵盖在 4.2.2 中

13.2.5

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

13.3.1

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

14.4.1

5.3.1 提供

14.4.2

此要求受其他输入验证要求的约束，如果缺少验证并不会引入实际的业务逻辑漏洞，则严重级别可能较低。例如，如果未能正确验证电话号码，会导致电话号码无法在信息页面上正确显示，从而无法直接带来安全隐患。

14.4.3

在 5.2.7 和 5.3.3 的范围内

14.4.5

在 6.2.1 和 9.2.1 的范围内

14.4.7

12.4.1 提供

14.5.3

14.5.2 提供

2.1.5

2.1.1 支持

2.1.6

2.1.1 支持

2.2.3

与 Casa 无关，因为相关风险可被其他反自动化控制覆盖

2.5.6

受其他密码保护

3.1.1

暴露风险较低，并受 ASVS 的其他控制的约束

3.2.1

暴露风险较低，并受 ASVS 的其他控制的约束

3.4.4

暴露风险较低，并受 ASVS 的其他控制的约束

3.4.5

暴露风险较低，并受 ASVS 的其他控制的约束

4.2.1

13.1.4 提供

5.2.8

在其他输入验证和清理检查的涵盖范围内

5.3.5 版

在其他输入验证和清理检查的涵盖范围内

7.4.1

由日志记录检查所涵盖

8.2.3

8.1.1 支持

9.1.1

在 6.2.1 和 9.2.1 的范围内

1.2.3

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.4.4

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.5.2

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.5.3

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.5.4

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.9.1

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.11.3

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.1

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.2

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.3

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.4

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.5

在 1.1.4、1.8.4 和 1.8.2 的范围内

1.14.6

在 1.1.4、1.8.4 和 1.8.2 的范围内

6.1.2

在 6.1.1 版中

6.1.3

在 6.1.1 版中

2.10.2

涵盖范围：2.5.4

2.2.1

在 11.1.4 的涵盖范围内

2.7.3

在 2.7.2 版本中

2.7.4

在 2.7.2 版本中

5.1.2

在反自动化控制的适用范围内

6.2.2

未定义的已批准加密算法

8.2.1 版

在 8.1.1 的范围内

9.1.2 版

在 9.2.1 版本中

9.1.3

在 9.2.1 版本中

5.5.1

在 1.8.2 版本中

14.2.1

在 1.14.6 版本中

3.3.4

对于使用无状态 AuthN/Z 的应用来说并不是这样。同意 NCC Group 的移除建议。这应该包含在 3.3.3 中

要求 ID

说明

1.1.4

验证应用的所有信任边界、组件和重要数据流的文档和正当理由。

1.8.1

确认所有敏感数据均已识别并归类到保护级别

1.8.2

确认所有保护级别都有一组相关的保护要求，例如加密要求、完整性要求、保留、隐私权和其他机密性要求，并且这些要求

。

2.1.1

验证用户设置的密码长度至少为 12 个字符

2.5.4 版

确认不存在共享帐号或默认帐号（例如“root”、

“admin”或“sa”）。

4.2.1

验证敏感数据和 API 是否受到针对不安全的直接对象引用 (IDOR) 攻击（包括创建、读取、更新和删除记录，例如创建或更新其他人的记录、查看所有人的记录或删除所有记录）的保护。

1.14.6

确认应用未使用不受支持、不安全或已废弃

客户端技术，例如 NSAPI 插件、Flash、Shockwave、ActiveX、

Silverlight、NACL 或客户端 Java 小程序。