Aaron Guzman	Anthony Weems	Barbara Schachner	Christopher Loessl	Clément Notin
Dan Cornell	Daniël Geerts	David Clarke	David Johansson	David Quisenberry
Erlend Oftedal	Fatih Ersinadim	Filip van Laenen	Geoff Baskwill	Glenn ten Cate
Grant Ongers	hello7s	Jacob Salassi	James Sulinski	Jason Axley
Jason Morrow	Javier Dominguez	Jet Anderson	Jim Newman	Jonathan Schnittger
Joseph Kerby	Kelby Ludwig	Lars Haulin	Lewis Ardern	lyz-code
Marc Aubry	Marco Schnüriger	Philippe De Ryck	Ralph Andalis	Ravi Balla
Rick Mitchell	Riotaro Okada	Robin Wood	Rogan Dawes	Ryan Goltry
Sajjad Pourali	Serg Belkommen	Siim Puustusmaa	Ståle Pettersen	Stuart Gunter
Tal Argoni	Tomasz Wrobel	Vincent De Schutter

应用程序安全验证标准建立在 2008 年 ASVS 1.0 到 2016 年 3.0 的涉及人员的肩膀上。今天仍然在 ASVS 中的许多结构和验证项目最初是由迈克·博伯斯基、杰夫·威廉姆斯和戴夫·威奇斯编写的，以及更多的贡献者。感谢所有以前参与的人。有关所有为早期版本做出贡献的项名的完整列表，请参阅每个早期版本。

前言

欢迎使用应用程序安全验证标准（ASVS）版本 4.0。ASVS 是一项由社区推动的工作，用于建立安全要求和控制框架，该框架侧重于定义设计、开发和测试现代 Web 应用程序和 Web 服务时所需的功能和非功能安全控制。

版本 4.0.2 是 v4.0 的第二个小修补版本，旨在修复拼写错误，以使要求更清晰，而无需做出重大更改（如更改要求或添加/删除要求）的重大变化。

ASVS v4.0 是过去十年来社区努力和行业反馈的高潮。我们试图使在任何安全软件开发生命周期中为各种不同的用例更容易地采用 ASVS。

我们预计，对于任何 Web 应用程序标准（包括 ASVS）的内容，很可能永远不会达成 100% 的一致意见。风险分析在某种程度上总是主观的，这在尝试以一刀切的标准进行概括时会产生挑战。但是，我们希望此版本中的最新更新是朝着正确方向迈出的一步，并增强这一关键行业标准中引入的概念。

4.0中的新内容

这个版本中最重要的变化是采用了NIST 800-63-3数字身份识别指南，引入了现代的、基于证据的高级认证控制。虽然我们预计在与高级认证标准保持一致方面会遇到一些阻力，但我们认为标准保持一致是非常必要的，主要是在另一个广受好评的应用安全标准是基于证据的情况下。

信息安全标准应尽量减少独特要求的数量，这样合规组织就不必在竞争或不兼容的控制措施上做决定。OWASP 2017年十大标准以及现在的OWASP应用安全验证标准现在已经与NIST 800-63在认证和会话管理方面保持一致。我们鼓励其他标准制定机构与我们、NIST和其他机构合作，以达成一套普遍接受的应用安全控制措施，从而最大限度地提高安全性，并最大限度地降低合规成本。

ASVS 4.0从头到尾全部重新编号。新的编号方案使我们能够填补长期消失的章节的空白，并使我们能够分割较长的章节，以尽量减少开发人员或团队必须遵守的控制数量。例如，如果一个应用程序没有使用JWT，那么关于会话管理中JWT的整个章节就不适用。

4.0中的新功能是对通用弱点列举（CWE）的全面映射，这是我们在过去十年中最常见的功能要求之一。CWE映射允许工具制造商和那些使用漏洞管理软件的人将其他工具和以前的ASVS版本的结果与4.0及以后的版本相匹配。为了给CWE条目腾出空间，我们不得不取消了 "Since"栏，因为我们完全重新编号了，这一栏的意义不如以前版本的ASVS。并非ASVS中的每个项目都有相关的CWE，由于CWE有大量的重复，我们试图使用最常用的而不是最接近的匹配。核查控制并不总是可以映射到相应的弱点。我们欢迎与CWE社区和更广泛的信息安全领域就缩小这一差距进行持续讨论。

我们努力全面满足并超越解决OWASP Top 10 2017和OWASP主动控制2018的要求。由于OWASP Top 10 2017是避免疏忽的最低要求，我们特意将除特定日志Top 10要求外的所有要求都定为1级控制，使OWASP Top 10采用者更容易步入实际安全标准。

我们努力全面满足并超越解决OWASP Top 10 2017和OWASP主动控制2018的要求。由于OWASP Top 10 2017是避免疏忽的最低要求，我们特意将除特定日志Top 10要求外的所有要求都定为1级控制，使OWASP Top 10采用者更容易步入实际安全标准。。

我们已经完成了ASVS从只对服务器端进行单体控制，到为所有现代应用和API提供安全控制的转变。在功能编程、无服务器API、移动、云、容器、CI/CD和DevSecOps、联盟等时代，我们不能继续忽视现代应用架构。现代应用的设计与2009年发布原始ASVS时构建的应用有很大不同。ASVS必须始终着眼于未来，这样我们才能为我们的主要受众--开发人员提供合理的建议。我们已经澄清或删除了任何假设应用程序是在单一组织拥有的系统上执行的要求。

由于ASVS 4.0的规模，以及我们希望成为所有其他ASVS工作的基线ASVS，我们已经停用了移动部分，转而采用移动应用安全验证标准（MASVS）。物联网附录将出现在未来的物联网ASVS中，由OWASP物联网项目负责。我们已经在附录C中包含了物联网ASVS的早期预览。我们感谢OWASP移动团队和OWASP物联网项目组对ASVS的支持，并期待未来与他们合作，提供互补的标准。

最后，我们删除了影响较小的控件，并使其退役。随着时间的推移，ASVS开始成为一套全面的控制措施，但并非所有的控制措施都能产生安全的软件。这种消除低影响项目的努力可以更进一步。在ASVS的未来版本中，共同弱点评分系统(CWSS)将有助于进一步确定那些真正重要的控制措施和那些应予淘汰的控制措施的优先次序。

从4.0版本开始，ASVS将只专注于成为领先的网络应用和服务标准，涵盖传统和现代应用架构，以及敏捷安全实践和DevSecOps文化

使用 ASVS

ASVS 有两个主要目标:

帮助组织开发和维护安全的应用程序。
以使安全服务厂商、安全工具厂商和消费者能够统一其要求和产品。

应用程序安全验证级别

应用程序安全验证标准定义了三个安全验证级别，每个级别的深度都不断增加.

ASVS 级别 1 用于低保证级别，完全可穿透测试
ASVS 级别 2 适用于包含敏感数据的应用程序，这需要保护，是大多数应用的推荐级别
ASVS 级别 3 适用于最关键的应用程序 - 执行高价值事务、包含敏感医疗数据的应用程序或任何需要最高信任级别的应用程序。

每个 ASVS 级别都包含安全要求列表。这些要求中的每一个也可以映射到开发人员必须内置到软件中的安全特定特性和功能。

图 1 - OWASP 应用程序安全验证标准 4.0 级别

第1级是唯一可以使用人类进行完全渗透测试的级别。所有其他级别的测试都需要访问文档、源代码、配置以及参与开发过程的人员。然而，即使L1允许发生 "黑盒"（没有文档和源码）测试，它也不是一种有效的保证活动，应该积极劝阻。恶意攻击者有大量的时间，大多数渗透测试在几周内就结束了。防御者需要建立安全控制，保护、发现和解决所有的弱点，并在合理的时间内检测和响应恶意行为者。恶意行为者的时间基本上是无限的，只需要一个漏洞的防御、一个弱点或遗漏的检测就可以成功。黑盒测试往往在开发结束后迅速进行，或者根本不进行测试，完全无法应对这种不对称性。

在过去的30多年里，黑盒测试一次又一次地被证明忽略了关键的安全问题，直接导致了越来越多的大规模漏洞。我们强烈鼓励使用广泛的安全保证和验证，包括用源代码主导的（混合）1级渗透测试取代渗透测试，并在整个开发过程中对开发人员和文档进行全面访问。金融监管机构不能容忍在无法访问账簿、交易样本或执行控制的人员的情况下进行外部财务审计。行业和政府必须在软件工程领域要求同样的透明度标准。

我们强烈鼓励在开发过程本身使用安全工具。DAST和SAST工具可以被构建流水线持续使用，以轻松发现本不该出现的安全问题。

在没有人工协助的情况下，自动工具和在线扫描无法完成一半以上的ASVS。如果需要对每个构建进行全面的自动化测试，那么结合自定义单元和集成测试，以及构建发起的在线扫描。业务逻辑缺陷和访问控制测试只能使用人工辅助。这些应该变成单元和集成测试。

如何使用此标准

使用应用程序安全验证标准的最佳方法之一是将其作为蓝图，创建一个特定于您的应用程序、平台或组织的安全编码检查表。根据您的用例对ASVS进行定制，将增加对您的项目和环境最重要的安全要求的关注。

Level 1 – 最低限度

如果一个应用程序能够充分防御容易发现的应用程序安全漏洞，幷包括在OWASP前10名和其他类似的检查清单中，则该应用程序达到了ASVS 1级。1级是所有应用程序应该努力达到的最低限度。它也可以作为多阶段工作的第一步，或者当应用程序不存储或处理敏感数据，因此不需要2级或3级更严格的控制时，它也很有用。1级控制可以通过工具自动检查，也可以在不访问源代码的情况下手动检查。我们认为1级是所有应用程序的最低要求。

对应用程序的威胁很可能来自于攻击者，他们使用简单和低工作量的技术来识别容易发现和容易利用的漏洞。这与坚定的攻击者形成鲜明对比，后者会花费集中精力专门针对应用程序。如果你的应用程序所处理的数据具有很高的价值，你很少会想停留在1级审查上。

Level 2 - 大多数应用程序

如果应用程序能够充分抵御与当今软件相关的大多数风险，它就达到 ASVS 级别2（或标准）。

级别 2 可确保安全控制到位、有效并在应用程序中使用。级别 2通常适用于处理重大企业对业务交易的应用程序，包括那些处理医疗保健信息、实现业务关键或敏感功能或处理其他敏感资产的应用程序，或完整性是保护其业务的关键方面（如游戏行业）阻止骗子和游戏黑客的行业。

对 2级应用程序的威胁通常是熟练且有积极性的攻击者，他们使用工具和技术专注于特定目标，这些工具和技术在发现和利用应用程序中的弱点方面非常有效。

Level 3 - 高价值、高保证或高安全性

ASVS第3级是ASVS内最高级别的核查。这一级别通常保留给需要大量安全核查的应用程序，如军事、卫生和安全、关键基础设施等领域的应用程序。

各组织可能会要求执行关键功能的应用程序达到ASVS级别3，因为这些应用程序的失败可能会严重影响组织的业务，甚至影响其生存能力。下文提供了关于ASVS 3级应用的示例指导。如果一个应用程序能够充分防御高级应用程序安全漏洞，并展示了良好安全设计的原则，则该应用程序达到了ASVS第3级（或高级）。

达到 ASVS 第 3级的应用程序比所有其他级别的应用程序需要对架构、编码和测试进行更深入的分析。一个安全的应用程序以有意义的方式模块化（以促进弹性、可扩展性，最重要的是，安全层），每个模块（通过网络连接和/或物理实例分离）都需要照顾自己的安全责任（深度防御），这些责任需要适当地记录下来。职责包括确保保密性（如加密）、完整性（如交易、输入验证）、可用性（如从容处理负载）、认证（包括系统之间）、不可抵赖性、授权和审计（日志）的控制。

在实践中应用 ASVS

不同的威胁有不同的动机。一些行业有独特的信息和技术资产以及特定领域的监管合规要求。

强烈鼓励各组织根据其业务性质深入研究其独特的风险特征，并根据该风险和业务要求确定适当的ASVS级别

如何参考 ASVS 要求

每个要求都有一个格式的标识符，格式为 <chapter><节><要求>其中每个元素都是一个数字，例如：1.11.3。

<章节> 值对应于需求来自的章节，例如：所有 1.#.# 要求都来自体系结构章节。
<节> 值对应于该章节中出现需求的部分，例如：所有 1.11.# 要求都位于体系结构章节的"业务逻辑体系结构要求"部分中。
<要求> 值标识章节和部分中的具体要求，例如：1.11.3，自本标准 4.0.2 版本起，该要求为:

验证所有高价值业务逻辑流（包括身份验证、会话管理和访问控制）是否都是安全的线程，并且能够抵抗检查时间和时间竞争条件。

标识符可能会在标准版本之间更改，因此最好使用其他文档、报表或工具的格式：v<version>-<chapter>.<section>。<requirement>，其中："版本"是 ASVS 版本标记。例如：v4.0.2-1.11.3 被理解为在版本 4.0.2 的"体系结构"章节的"业务逻辑体系结构要求"部分中具体指的是第 3 个要求。（这可以概括为 v<version>-<requirement_identifier>。

注意：版本部分前面的 v 是小写。

如果标识符在未包含 v<version> 元素的情况下使用，则应假定它们引用最新的应用程序安全验证标准内容。显然，随着标准的增长和更改，这将成为问题，这就是为什么编写者或开发人员应该包括版本元素.

ASVS 要求列表以 CSV、JSON 和其他格式提供，这些格式可能有助于参考或编程使用。

评估和认证

OWASP 对 ASVS 认证和信任标志的立场

OWASP作为一个供应商中立的非营利组织，目前不对任何供应商、验证器或软件进行认证。

所有这些保证声明、信任标记或认证都没有经过OWASP的正式审查、注册或认证，因此，依赖这种观点的组织需要谨慎对待对任何声称ASVS认证的第三方或信任标记的信任。

这不应该阻止组织提供这种保证服务，只要它们不声称OWASP的官方认证。

认证组织指南

应用程序安全验证标准可用作应用程序的开放帐簿验证，包括对关键资源（如架构师和开发人员、项目文档、源代码、对测试系统的身份验证访问（包括访问每个角色中的一个或多个帐户）的开放和不受限制的访问，特别是对于 L2 和 L3 验证。

从历史上看，渗透测试和安全代码审查包括"例外"问题，即只有失败的测试才出现在最终报告中。认证组织必须在任何报告中包括验证的范围（特别是当关键组件超出了范围（如SSO身份验证）时），验证结果的摘要（包括通过测试和失败测试），并明确指示如何解决失败的测试。

某些验证要求可能不适用于正在测试的应用程序。例如，如果您向客户提供无状态服务层 API，则 V3会话管理中的许多要求并不直接适用。在这种情况下，认证组织仍可要求完全遵守 ASVS，但必须在任何报告中明确说明不适用此类排除的验证要求的原因。

保留详细的工作文件、截图或视频、可靠和反复利用某个问题的脚本，以及测试的电子记录，如截取代理日志和相关的笔记（如清理清单），被认为是标准的行业惯例，对于最值得怀疑的开发人员来说，作为调查结果的证明确实有用。仅仅运行一个工具并报告故障是不够的，这并不能（完全）提供足够的证据来证明认证层面的所有问题都经过了彻底的测试和检验。在有争议的情况下，应该有足够的保证证据来证明每一个被验证的需求确实已经被测试过。

测试方法

认证组织可以自由选择适当的测试方法，但应在报告中注明。

根据所测试的应用程序和核查要求，可以使用不同的测试方法来获得类似的结果。例如，验证一个应用程序的输入核查机制的有效性，可以通过人工渗透测试或通过源代码分析来进行分析。

自动安全测试工具的作用

鼓励使用自动渗透测试工具提供尽可能多的覆盖范围。

无法仅使用自动渗透测试工具完全完成 ASVS 验证。虽然 L1 中的大多数要求都可以使用自动测试执行，但总体大多数要求都无法用于自动渗透测试。

请注意，随着应用安全行业的成熟，自动测试和手动测试之间的界限已经模糊。自动工具通常由专家手动调整，手动测试人员通常利用各种自动化工具。

渗透测试的作用

在4.0版本中，我们决定使L1完全可以进行渗透测试，而无需访问源代码、文档或开发人员。两个日志项目，需要符合OWASP Top 10 2017 A10的要求，将需要访谈、截图或其他证据收集，就像在OWASP Top 10 2017中一样。然而，在没有获得必要信息的情况下进行测试并不是一种理想的安全验证方法，因为它错过了审查源头、识别威胁和缺失控制的可能性，并在更短的时间内执行更彻底的测试。

在执行 L2 或 L3 评估时，需要尽可能地访问开发人员、文档、代码，并访问具有非生产数据的测试应用程序。在这些级别进行的渗透测试需要这种级别的访问权限，我们称之为 "混合审查 "或 "混合渗透测试"。

ASVS 的其他用途

除了用于评估应用程序的安全性外，我们还确定了 ASVS 的许多其他潜在用途。

作为详细的安全架构指南

应用安全验证标准比较常见的用途之一是作为安全架构师的资源。Sherwood应用业务安全架构(SABSA)缺少大量的信息，而这些信息是完成一个彻底的应用安全架构审查所必需的。ASVS可以用来填补这些空白，允许安全架构师针对常见问题选择更好的控制措施，例如数据保护模式和输入验证策略。

作为现成的安全编码清单的替代品

许多组织可以通过采用 ASVS、选择三个级别之一或分叉 ASVS 以及以特定域方式更改每个应用程序风险级别所需的内容而受益。只要保持可追溯性，我们鼓励这种类型的分叉，这样，如果应用通过了要求 4.1，这意味着分叉副本与标准副本在不断发展时相同。

作为自动化单元和集成测试指南

ASVS设计为高度可测试，只有体系结构和恶意代码要求除外。通过构建单元和集成测试来测试特定且相关的模糊和滥用案例，应用程序几乎会针对每个生成进行自我验证。例如，可以为登录控制器的测试套件编写其他测试，测试常见默认用户名、帐户枚举、暴力破解、LDAP 和 SQL 注入以及 XSS的用户名参数。同样，对密码参数的测试应包括通用密码、密码长度、空字节注入、删除参数、XSS等。

用于安全开发培训

ASVS还可用于定义安全软件的特性。许多"安全编码"课程只是道德黑客课程与编码技巧的轻描淡写。这不一定帮助开发人员编写更安全的代码。相反，安全开发课程可以使用ASVS，重点关注 ASVS 中的主动控制，而不是不做的事情的十大负面内容。

作为敏捷应用程序安全性的驱动程序

在敏捷开发过程中，ASVS可以作为一个框架来定义团队为获得安全产品而需要执行的具体任务。一种方法可能是：从第1级开始，根据ASVS对指定级别的要求核查具体的应用程序或系统，找出缺少的控制措施，并在积压中提出具体的任务。这有助于特定任务的优先级排序（或梳理），并使敏捷过程中的安全可见。这也可以用来确定组织中审计和审查任务的优先级，特定的ASVS需求可以成为特定团队成员审查、重构或审计的驱动力，并作为最终目标。

作为指导安全软件采购的框架

ASVS是一个伟大的框架，可帮助安全软件采购或自定义开发服务的采购。买方可以简单地设定一个要求，即他们想要采购的软件必须在 ASVS 级别 X 开发，并要求卖方证明该软件满足 ASVS 级别 X。与 OWASP安全软件合同附件结合使用时，这效果很好

V1：架构、设计和威胁建模要求

控制目标

安全架构在许多组织中几乎已经成为一门失传的手艺。在DevSecOps时代，企业架构师的时代已经过去。应用安全领域必须迎头赶上，采用敏捷安全原则，同时将领先的安全架构原则重新介绍给软件从业者。架构不是一种实现，而是一种思考问题的方式，它有可能有很多不同的答案，没有一个单一的"正确"答案。很多时候，安全问题被认为是不灵活的，要求开发人员以特定的方式修复代码，而开发人员可能知道更好的解决问题的方法。对于架构来说，没有单一的、简单的解决方案，假装不这样做是对软件工程领域的一种伤害。

一个网络应用的具体实现很可能在整个生命周期中不断地被修改，但整体架构可能很少改变，而是缓慢地发展。安全架构是相同的--今天我们需要认证，明天我们需要认证，五年后我们也需要认证。如果我们今天做出正确的决定，如果我们选择和重复使用符合架构的解决方案，我们可以节省大量的精力、时间和金钱。例如，十年前，多因素身份验证很少被实施。

如果开发人员选择了单一的安全身份提供商模式，如SAML联合身份，那么身份提供商可以进行更新，以纳入新的要求，如NIST 800-63的合规性，同时不改变原有应用的接口。如果许多应用程序共享相同的安全架构，从而共享该相同的组件，那么它们都可以一次从这种升级中受益。然而，SAML不会一直作为最佳或最合适的认证解决方案--随着需求的变化，它可能需要换成其他解决方案。这样的改变要么很复杂，成本太高，以至于需要彻底重写，要么在没有安全架构的情况下完全不可能。

在本章中，ASVS涵盖了任何健全安全架构的主要方面：可用性、保密性、处理完整性、不可抵赖性和隐私性。这些安全原则中的每一项都必须内置在所有应用程序中，并且是与生俱来的。至关重要的是 "向左移动"，从开发人员启用安全编码检查清单、指导和培训、编码和测试、构建、部署、配置和操作开始，到后续的独立测试结束，以确保所有的安全控制都存在并发挥作用。最后一步曾经是我们作为一个行业所做的一切，但当开发人员每天将代码推送到生产中几十次或几百次时，这已经不够了。应用安全专业人员必须跟上敏捷技术的步伐，这意味着采用开发人员工具，学习代码，与开发人员一起工作，而不是在其他人都离开几个月后批评项目（鞭尸）。

V1.1 安全软件开发生命周期要求 #	描述	L2	L3	CWE
1.1.1	验证安全软件开发生命周期的使用，该生命周期解决了所有开发阶段的安全性问题	✓	✓
1.1.2	验证每个设计更改或规划使用威胁建模，以识别威胁、规划对策、促进适当的风险响应并指导安全测试。	✓	✓	1053
1.1.3	验证所有用户情景和功能是否都包含功能性安全约束，例如"作为用户，我应该能够查看和编辑我的个人资料。我不应查看或编辑其他人的个人资料"	✓	✓	1110
1.1.4	验证应用程序的所有信任边界、组件和重要数据流的文档以及原由。	✓	✓	1059
1.1.5	验证应用程序高级体系结构和所有连接的远程服务的定义和安全分析。	✓	✓	1059
1.1.6	验证集中、简单（设计经济）、经过审查、安全和可重用的安全控制的实施，以避免重复、缺失、无效或不安全的控制。	✓	✓	637
1.1.7	验证所有开发人员和测试人员的安全编码清单、安全要求、指南或策略的可用性。	✓	✓	637

V1.2 身份验证体系结构要求

在设计身份验证时，如果攻击者可以通过调用呼叫中心并回答常见问题来重置帐户，则是否具有启用强硬件的多重身份验证并不重要。校对身份时，所有认证路径必须具有相同的强度。

#	描述	L2	L3	CWE
1.2.1	验证所有应用程序组件、服务和服务器的唯一或特殊低特权操作系统帐户的使用。	✓	✓	250
1.2.2	验证应用程序组件（包括 API、中间件和数据层）之间的通信是否经过身份验证。组件应具有所需的最低限度的特权。	✓	✓	306
1.2.3	验证应用程序是否使用已知安全的单个经过审查的身份验证机制，可以扩展为包括强身份验证，并有足够的日志记录和监视来检测帐户滥用或违规。	✓	✓	306
1.2.4	验证所有身份验证路径和身份管理 API 都实现一致的身份验证安全控制强度。	✓	✓	306

V1.3 会话管理体系结构要求

这是未来体系结构要求的占位符。

V1.4 访问控制架构要求 #	描述	L2	L3	CWE
1.4.1	验证访问控制网关、服务器和无服务器功能等受信任的执行点是否实施了访问控制。切勿在客户端实施访问控制。	✓	✓	602
1.4.2	验证所选的访问控制解决方案是否足够灵活，足以满足应用程序的需求。	✓	✓	284
1.4.3	核查函数、数据文件、URL、控制器、服务和其他资源中的最低特权原则的执行情况。这意味着防止欺骗和提高特权。	✓	✓	272
1.4.4	验证应用程序使用单一且经过良好审查的访问控制机制来访问受保护的数据和资源。所有请求必须通过此单一机制，以避免复制和粘贴或不安全的替代路径。	✓	✓	284
1.4.5	验证是否使用了属性或基于功能的访问控制，代码检查用户对功能/数据项的授权，而不仅仅是他们的角色。	✓	✓	275

V1.5 输入和输出架构要求

在 4.0 中，我们已将"服务器端"一词作为加载的信任边界术语。信任边界仍然令人担心 - 在不受信任的浏览器或客户端设备上做出决策是可绕过的。但是，在当今的主流体系结构部署中，信任强制点发生了巨大变化。因此，在 ASVS 中使用术语"受信任服务层"时，我们指的是任何受信任的实施点，无论位置如何，例如微服务、无服务器 API、服务器端、具有安全引导、合作伙伴或外部 API 的客户端设备上的受信任 API 等。

此处的"不受信任的客户端"术语是指呈现表示层的客户端技术，通常称为"前端"技术。此处的术语"序列化"不仅指像值数组一样通过线发送数据，或者接收和读取 JSON 结构，还指传递可以包含逻辑的复杂对象

#	描述	L2	L3	CWE
1.5.1	验证输入和输出要求是否清楚地定义如何根据类型、内容和适用的法律、法规和其他策略合规性处理和处理数据。	✓	✓	1029
1.5.2	在与不受信任的客户机通信时，验证是否没有使用序列化。如果无法做到这一点，确保实施适当的完整性控制（如果发送敏感数据，则可能进行加密），以防止反序列化攻击，包括对象注入。	✓	✓	502
1.5.3	验证输入验证是否在受信任的服务层上强制实施。	✓	✓	602
1.5.4	验证输出编码是否发生在预期要执行的解释器附近或由解释器进行。	✓	✓	116

V1.6 加密体系结构要求

应用程序需要使用强大的加密体系结构进行设计，以根据其分类保护数据资产。加密一切是浪费，不加密任何东西在法律上都是疏忽大意。必须取得平衡，通常在体系结构或高级设计、赶进度设计或体系结构峰值期间。在进行加密或改造时设计密码，安全实施成本必然比从一开始构建成本高得多。

体系结构要求是整个代码库固有的，因此很难单元或集成测试。在整个编码阶段，在编码标准中需要考虑体系结构要求，并且应在安全体系结构、同行或代码评审或回顾期间进行审查。

#	描述	L2	L3	CWE
1.6.1	验证是否有用于管理加密密钥的明确策略，并且加密密钥生命周期是否遵循密钥管理标准（如 NIST SP 800-57）。	✓	✓	320
1.6.2	验证加密服务的使用者是否使用密钥保管库或基于 API的替代方案来保护密钥材料和其他机密。	✓	✓	320
1.6.3	验证所有密钥和密码是否可替换，并且是重新加密敏感数据定义良好的过程的一部分。	✓	✓	320
1.6.4	验证体系结构是否将客户端机密（如对称密钥、密码或 API令牌）视为不安全，并且从不使用它们来保护或访问敏感数据.	✓	✓	320

V1.7 错误、日志记录和审核体系结构要求

#	描述	L1	L2	L3	CWE
1.7.1	验证系统中是否使用了通用日志记录格式和方法。		✓	✓	1009
1.7.2	验证日志是否安全地传输到优选的远程系统，以便进行分析、检测、警报和上报。		✓	✓

V1.8 数据保护和隐私体系结构要求

#	描述	L1	L2	L3	CWE
1.8.1	验证所有敏感数据是否已识别并分为保护级别。		✓	✓
1.8.2	验证所有保护级别是否都有一组关联的保护要求，例如加密要求、完整性要求、保留、隐私和其他机密性要求，以及这些要求是否应用于体系结构中。		✓	✓

V1.9 通信体系结构要求

#	描述	L1	L2	L3	CWE
1.9.1	验证应用程序加密组件之间的通信，特别是当这些组件在不同的容器、系统、站点或云提供商中时。		✓	✓	319
1.9.2	验证应用程序组件是否验证通信链路中每一方的真实性，以防止中间人攻击。例如，应用程序组件应验证<br/>TLS 证书和链。		✓	✓	295

V1.10 恶意软件体系结构要求

#	描述	L1	L2	L3	CWE
1.10.1	核实是否使用了源代码控制系统，并有程序确保签到时附有问题或变更单。源码控制系统应具有访问控制和可识别的用户，以便对任何更改进行跟踪。		✓	✓	284

V1.11 业务逻辑架构要求

#	描述	L2	L3	CWE
1.11.1	根据所有应用程序组件提供的业务或安全功能，验证它们的定义和文档。	✓	✓	1059
1.11.2	验证所有高价值业务逻辑流（包括身份验证、会话管理和访问控制）不共享不同步状态。	✓	✓	362
1.11.3	验证所有高价值业务逻辑流（包括身份验证、会话管理和访问控制）是否都是安全的线程，并且能够抵抗检查时间和时间竞争条件。		✓	367

V1.12 安全文件上传体系结构要求

#	描述	L1	L2	L3	CWE
1.12.1	验证用户上传的文件是否存储在 Web 根目录之外。		✓	✓	552
1.12.2	验证用户上传的文件（如果需要从应用程序显示或下载）是否由八位组流下载或从不相关的域（如云文件存储桶）提供。实施合适的内容安全策略（CSP）以降低来自 XSS 矢量或上载文件的其他攻击的风险。		✓	✓	646

V1.13 API 架构要求

这是未来体系结构要求的占位符。 V1.14 配置架构要求 #	描述	L2	L3	CWE
1.14.1	通过定义良好的安全控制、防火墙规则、API 网关、反向代理、基于云的安全组或类似机制，验证不同信任级别的组件的隔离。	✓	✓	923
1.14.2	验证二进制签名、受信任连接和经过验证的终结点是否用于将二进制文件部署到远程设备。	✓	✓	494
1.14.3	验证构建流水线是否警告过期或不安全的组件，并采取适当的操作。	✓	✓	1104
1.14.4	验证构建流水线是否包含自动生成和验证应用程序的安全部署的生成步骤，尤其是在应用程序基础结构是软件定义的（如云环境生成脚本）时。	✓	✓
1.14.5	验证应用程序部署是否足够沙盒、容器化和/或隔离在网络级别，以延迟和阻止攻击者攻击其他应用程序，尤其是当他们执行敏感或危险的操作（如反序列化）时。	✓	✓	265
1.14.6	验证应用程序不使用不受支持、不安全或弃用的客户端技术，如 NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.	✓	✓	477

参考文献

有关详细信息，请参阅:

V2：身份验证验证要求

控制目标

身份验证是指确定或确认某人（或某物）是真实的，并且某人或某设备所做的主张是正确的，能够抵御冒充，防止密码被恢复或拦截的行为。

ASVS刚发布时，用户名+密码是高安全系统之外最常见的认证方式。多因素认证(MFA)在安全圈内被普遍接受，但在其他地方很少被要求。随着密码泄露事件的增多，认为用户名在某种程度上是保密的，而密码则是未知的，这种想法使得许多安全控制措施无法成立。例如，NIST 800-63认为用户名和基于知识的身份验证（KBA）是公共信息，短信和电子邮件通知是 "受限 "的身份验证器类型，而密码是预先破解的。这种现实使得基于知识的身份验证器、短信和电子邮件恢复、密码历史、复杂性和轮换控制毫无用处。这些控制总是不那么有用，经常迫使用户每隔几个月就拿出弱密码，但随着超过50亿次用户名和密码泄露事件的发布，是时候继续前进了。

在ASVS的所有章节中，身份验证和会话管理章节变化最大。采用有效的、基于证据的领先实践对许多人来说将是一个挑战，这完全没有问题。我们现在就必须开始向后密码的未来过渡。

NIST 800-63 - 现代的循证认证标准

NIST 800-63b 是一种现代的循证标准，代表最好的建议，无论适用性如何。该标准对全世界所有组织都很有帮助，但尤其适用于美国机构和与美机构打交道的组织。

NIST 800-63 术语一开始可能会有点混乱，尤其是如果您只使用用户名 + 密码身份验证。现代身份验证的进步是必要的，因此我们必须引入将来将变得司空见惯的术语，但我们确实理解在行业确定这些新术语之前理解的困难。我们在本章末尾提供了一个词汇表来提供帮助。我们重新表述了许多要求，以满足要求的意图，而不是要求的字母。例如，当 NIST 在整个本标准中使用"记住的秘密"时，ASVS 使用术语"密码"。

ASVS V2 身份验证、V3 会话管理以及较小程度上，V4 访问控制已调整为所选 NIST 800-63b 控件的合规子集，侧重于常见威胁和通常利用的身份验证弱点。如果需要完全 NIST 800-63 合规性，请查看 NIST 800-63。

选择适当的 NIST AAL 级别

应用程序安全验证标准已尝试将 ASVS L1 映射到 NIST AAL1 要求，L2 映射到 AAL2，将 L3 映射到 AAL3。但是，ASVS 级别 1 作为"基本"控件的方法不一定是验证应用程序或 API 的正确 AAL 级别。例如，如果应用程序是 3 级应用程序或具有 AAL3 的法规要求，则应在 V2 节和 V3 会话管理中选择级别 3。选择符合 NIST 的身份验证断言级别（AAL）应根据 NIST 800-63b 准则执行，如 NIST 800-63b Section6.2. 第 6.2 节中选择AAL 中所述

V2.1 密码安全要求

密码，称为"记忆的秘密"由NIST 800-63，包括密码，PIN，解锁模式，选择正确的小猫或其他图像元素，和密码。它们通常被认为是"您知道的东西"，并经常用作单因素验证器。继续使用单因素身份验证面临重大挑战，包括Internet上披露的数十亿有效用户名和密码、默认或弱密码、彩虹表和最常见的密码的有序字典。

应用程序应强烈鼓励用户注册多重身份验证，并且应允许用户重新使用已拥有令牌（如 FIDO 或 U2F 令牌）或链接到提供多重身份验证的凭据服务提供商。

凭据服务提供商（CSP）为用户提供联合标识。用户通常具有多个具有多个 CSP的标识，例如使用 Azure AD、Okta、Ping 标识或 Google 的企业标识，或使用Facebook、Twitter、Google或微信的用户标识来命名几个常见替代方法。此列表不是对这些公司或服务的认可，而只是鼓励开发人员考虑许多用户具有许多已确立的身份的现实。组织应考虑根据CSP的身份证明强度的风险简介与现有用户身份集成。例如，政府机构不太可能接受社交媒体标识作为敏感系统的登录，因为创建虚假身份或扔掉身份很容易，而移动游戏公司很可能需要与主要社交媒体平台集成，以扩大其活跃玩家基础。

#	描述	L1	L2	L3	CWE	NIST §
2.1.1	验证用户设置的密码长度至少为 12 个字符（在合并多个空格后）。	✓	✓	✓	521	5.1.1.2
2.1.2	验证密码允许 64 个字符或更长时间，但可能不超过 128 个字符。	✓	✓	✓	521	5.1.1.2
2.1.3	验证未执行密码截断。但是，连续的多个空格可以替换为单个空格。	✓	✓	✓	521	5.1.1.2
2.1.4	验证密码中是否允许任何可打印的 Unicode 字符，包括语言中性字符（如空格和表情符号）。	✓	✓	✓	521	5.1.1.2
2.1.5	验证用户可以更改其密码。	✓	✓	✓	620	5.1.1.2
2.1.6	验证密码更改功能是否需要用户的当前密码和新密码。	✓	✓	✓	620	5.1.1.2
2.1.7	验证在帐户注册、登录和密码更改期间提交的密码是否针对一组违反密码（例如与系统密码策略匹配的前 1，000 或 10，000 个最常用密码）或使用外部 API 进行检查。如果使用 API，应使用零知识证明或其他机制来确保不发送或使用纯文本密码来验证密码的泄露状态。如果密码被违反，应用程序必须要求用户设置新的未违反密码。	✓	✓	✓	521	5.1.1.2
2.1.8	验证是否提供了密码强度规则来帮助用户设置更强的密码。	✓	✓	✓	521	5.1.1.2
2.1.9	验证没有限制允许的字符类型的密码组合规则。不应对大写或小写或数字或特殊字符是必需的。	✓	✓	✓	521	5.1.1.2
2.1.10	验证没有定期凭据轮换或密码历史记录要求。	✓	✓	✓	263	5.1.1.2
2.1.11	验证是否允许"粘贴"功能、浏览器密码帮助程序以及外部密码管理器。	✓	✓	✓	521	5.1.1.2
2.1.12	验证用户可以选择暂时查看整个掩蔽密码，或暂时查看没有内置功能的平台上密码的最后一个键入字符。	✓	✓	✓	521	5.1.1.2

注意: 允许用户查看其密码或暂时查看最后一个字符的目标是提高凭据输入的可用性，特别是围绕使用较长的密码、密码短语和密码管理器。包括此要求的另一个原因是阻止或防止测试报告不必要地要求组织重写内置平台密码字段行为，以删除这种现代用户友好的安全体验。

V2.2 一般身份验证器要求

身份验证器敏捷性对于面向未来的应用程序至关重要。重构应用程序验证器，允许根据用户首选项设置其他身份验证器，并允许有条不紊地停用弃用或不安全的身份验证器。

NIST 认为电子邮件和 SMS 是"受限"的身份验证器类型，它们可能会从 NIST 800-63 中删除，因此 ASVS将来会在某个时候被删除。应用程序应规划不需要使用电子邮件或短信的路线图。

#	描述	L1	L2	L3	CWE	NIST §
2.2.1	验证反自动化控制是否有效可缓解违反的凭据测试、暴力攻击和帐户锁定攻击。此类控制包括阻止最常见的密码、软锁定、速率限制、CAPTCHA、尝试之间的不断增加延迟、IP 地址限制或基于风险的限制，如位置、首次登录设备、最近解锁帐户的尝试或类似。验证单个帐户每小时失败次数不超过 100 次。	✓	✓	✓	307	5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2
2.2.2	验证弱身份验证器（如 SMS 和电子邮件）的使用是否仅限于辅助验证和事务审批，而不是替代更安全的身份验证方法。验证在弱方法之前是否提供了更强大的方法，用户是否意识到了风险，或者是否采取了适当的措施来限制帐户泄露的风险。	✓	✓	✓	304	5.2.10
2.2.3	验证在更新身份验证详细信息（如凭据重置、电子邮件或地址更改、从未知或危险位置登录）后是否向用户发送安全通知。首选使用推送通知（而不是短信或电子邮件），但在没有推送通知的情况下，只要通知中未披露敏感信息，短信或电子邮件是可以接受的。	✓	✓	✓	620
2.2.4	验证抗冒充性，防止网络钓鱼，如使用多因素认证、带有意图的加密设备（如带有推送认证的连接密钥），或在更高的AAL级别，使用客户端证书。			✓	308	5.2.5
2.2.5	验证证书服务提供商（CSP）和验证身份验证的应用程序是否分开，两个终结点之间是否具有相互身份验证的 TLS。			✓	319	5.2.6
2.2.6	通过强制使用一次密码（OTP）设备、加密身份验证器或查找代码来验证重播阻力。			✓	308	5.2.8
2.2.7	通过要求输入 OTP 令牌或用户启动的操作（如在 FIDO 硬件密钥上按下按钮）验证身份验证意图。			✓	308	5.2.9

V2.3 身份验证器生命周期要求

身份验证器是密码、软令牌、硬件令牌和生物识别设备。身份验证器的生命周期对应用程序的安全性至关重要。如果有人可以在没有身份证据的帐户自行注册帐户，则对标识断言的信任就很少了。对于像Reddit 这样的社交媒体网站，这完全没问题。对于银行系统来说，更加注重凭据和设备的注册和颁发对于应用程序的安全性至关重要。

注意：密码不得有最长使用期限，不得进行密码轮换。密码应检查是否被破解，而不是定期更换。

#	描述	L1	L2	L3	CWE	NIST §
2.3.1	验证系统生成的初始密码或激活代码应安全地随机生成，应至少 6 个字符长，并且可能包含字母和数字，并在短时间内过期。不得允许这些初始机密成为长期密码。	✓	✓	✓	330	5.1.1.2 / A.3
2.3.2	验证是否支持注册和使用订阅者提供的身份验证设备，如 U2F 或 FIDO 令牌。		✓	✓	308	6.1.3
2.3.3	验证续订说明是否发送时间足够，以续订有时限的身份验证器。		✓	✓	287	6.1.4

V2.4 凭据存储要求

架构师和开发人员在构建或重构代码时应遵守此部分。本节只能通过源代码审查或通过安全单元或集成测试进行完全验证。渗透测试无法识别这些问题中的任何一个。

NIST 800-63 B 节 5.1.1.2 和BSI Kryptgraphische Verfahren： Empfehlungen 和 Schlussellngen （2018）中详细介绍了批准的双向键派生函数列表。可以选择最新的国家或区域算法和密钥长度标准，以代替这些选择.

此部分无法进行渗透测试，因此控件不会标记为L1。但是，如果凭据被盗，此部分对凭据的安全性至关重要，因此，如果为体系结构或编码准则或源代码审查清单编写ASVS，请将这些控件放回您的私有版本中的 L1。

#	描述	L2	L3	CWE	NIST §
2.4.1	验证密码是否以抗脱机攻击的形式存储。应使用经批准的单向密钥派生或密码哈希函数对密码进行salt和哈希处理。密钥派生和密码哈希函数在生成密码哈希时将密码、salt和成本系数作为输入。	✓	✓	916	5.1.1.2
2.4.2	验证salt的长度至少为 32 位，并任意选择以最大限度地减少存储哈希之间的salt值冲突。对于每个凭据，应存储唯一的salt值和生成的哈希。	✓	✓	916	5.1.1.2
2.4.3	验证如果使用 PBKDF2，迭代计数应与验证服务器性能允许的一样大，通常至少 100，000 次迭代。	✓	✓	916	5.1.1.2
2.4.4	验证是否使用 bcrypt，工作因子应与验证服务器性能允许的一样大，通常至少为 13。	✓	✓	916	5.1.1.2
2.4.5	验证是否使用机密且仅对验证者已知的 salt 值执行密钥派生函数的附加迭代。使用经批准的随机位生成器 [SP 800-90Ar1] 生成salt值，并提供 SP 800-131A 最新修订版中指定的最小安全强度。秘密salt值应与哈希密码分开存储（例如，在硬件安全模块等专用设备中）。	✓	✓	916	5.1.1.2

如果提到美国标准，可以根据要求使用区域或当地标准来代替或补充美国标准。

V2.5 凭据恢复要求 #	描述	L1	L2	L3	CWE	NIST §
2.5.1	验证系统生成的初始激活或恢复密钥未以明文发送给用户。	✓	✓	✓	640	5.1.1.2
2.5.2	验证不存在密码提示或基于知识的身份验证（所谓的"机密问题"）。	✓	✓	✓	640	5.1.1.2
2.5.3	验证密码凭据恢复不会以任何方式显示当前密码。	✓	✓	✓	640	5.1.1.2
2.5.4	验证共享或默认帐户不存在 (e.g. "root", "admin", or "sa").	✓	✓	✓	16	5.1.1.2 / A.3
2.5.5	验证是否更改或替换了身份验证因子，是否通知用户此事件。	✓	✓	✓	304	6.1.2.3
2.5.6	验证忘记的密码和其他恢复路径使用安全恢复机制，例如基于时间的 OTP （TOTP）或其他软令牌、移动推送或其他脱机恢复机制。	✓	✓	✓	640	5.1.1.2
2.5.7	核实如果OTP或多因素认证因子丢失，身份证明的证据是否与注册时相同。		✓	✓	308	6.1.2.3

V2.6 查找秘密验证人要求

查找秘密是预先生成的秘密代码列表，类似于交易授权号（TAN）、社交媒体恢复代码或包含一组随机值的网格。这些被安全地分发到用户手中。这些查找码只使用一次，一旦全部使用完毕，查找秘密列表就会被丢弃。这种类型的验证器被认为是 "你使用过的东西"。

#	描述	L2	L3	CWE	NIST §
2.6.1	验证查机密只能使用一次	✓	✓	308	5.1.2.2
2.6.2	验证查找机密是否具有足够的随机性（112位），如果小于112位，则用唯一的随机32位进行salt，并用批准的单向哈希进行哈希	✓	✓	330	5.1.2.2
2.6.3	验证查找机密是否可抵抗脱机攻击，如可预测值.	✓	✓	310	5.1.2.2

V2.7 带外验证器要求

过去，带外验证器的常见是包含密码重置链接的电子邮件或短信。攻击者使用此弱机制重置他们尚无法控制的帐户，例如接管此人的电子邮件帐户以及重新使用任何发现的重置链接。有更好的方法来处理带外验证。

带外安全身份验证器是可以通过安全的辅助通道与验证器通信的物理设备。示例包括向移动设备推送通知。这种类型的验证器被视为"您拥有的东西"。当用户希望进行身份验证时，验证应用程序通过第三方服务直接或间接连接到验证器，向带外验证器发送消息。该消息包含身份验证代码（通常是随机的六位数字或模式审批对话框）。验证应用程序等待通过主通道接收身份验证代码，并将接收值的哈希值与原始身份验证代码的哈希值进行比较。如果它们匹配，则带外验证器可以假定用户已过身份验证。

ASVS 假定只有少数开发人员将开发新的带外身份验证器（如推送通知），因此以下 ASVS 控件适用于验证器，如身份验证API、应用程序和单点登录实现。如果开发新的带外验证器，请参阅 NIST 800-63B § 5.1.3.1.

不允许不安全的带外身份验证器（如电子邮件和 VOIP）。PSTN 和 SMS 身份验证目前受NIST 的"限制"，应弃用推送通知或类似通知。

#	描述	L1	L2	L3	CWE	NIST §
2.7.1	验证默认情况下是否未提供带外（NIST"受限"）的明文验证器（如 SMS 或 PSTN），并且首先提供更强大的替代方法（如推送通知）。	✓	✓	✓	287	5.1.3.2
2.7.2	验证带外验证器在 10 分钟后是否过期带身份验证请求、代码或令牌。	✓	✓	✓	287	5.1.3.2
2.7.3	验证带外验证器身份验证请求、代码或令牌是否仅对原始身份验证请求可用一次，且仅对原始身份验证请求可用。	✓	✓	✓	287	5.1.3.2
2.7.4	验证带外验证器和验证器是否通过安全的独立通道进行通信。	✓	✓	✓	523	5.1.3.2
2.7.5	验证带外验证器是否仅保留身份验证代码的哈希版本。		✓	✓	256	5.1.3.2
2.7.6	验证初始身份验证代码是否由包含至少 20 位的安全随机数生成器生成（通常为 6 个数字随机数就足够了）。		✓	✓	310	5.1.3.2

V2.8 单因素或多因素一次验证器要求

单因素一次密码（OTP）是物理或软令牌，显示不断变化的伪随机一次质询。这些设备使网络钓鱼（模拟）变得困难，但不是不可能。这种类型的验证器被视为"您拥有的东西"。多因素令牌类似於单因素OTP，但需要有效的 PIN 码、生物识别解锁、USB 插入或 NFC 配对或一些附加值（如交易签名计算器）才能输入以创建最终 OTP。

#	描述	L1	L2	L3	CWE	NIST §
2.8.1	验证基于时间的 OTP 在到期前是否具有定义的生存期。	✓	✓	✓	613	5.1.4.2 / 5.1.5.2
2.8.2	验证用于验证提交的 OTP 的对称密钥是否受到高度保护，例如使用硬件安全模块或基于操作系统的安全密钥存储。		✓	✓	320	5.1.4.2 / 5.1.5.2
2.8.3	验证在 OTP 的生成、种子设定和验证中是否使用了经批准的加密算法。		✓	✓	326	5.1.4.2 / 5.1.5.2
2.8.4	验证基于时间的 OTP 在有效期内只能使用一次。		✓	✓	287	5.1.4.2 / 5.1.5.2
2.8.5	验证如果在有效期内重新使用基于时间的多因素 OTP 令牌，则记录并拒绝该令牌，并发送安全通知到设备的持有者。		✓	✓	287	5.1.5.2
2.8.6	验证物理单因素 OTP 生成器在发生盗窃或其他损失时可被撤销。确保无论位于什么位置，在已登录会话中立即执行吊销。		✓	✓	613	5.2.1
2.8.7	验证生物识别身份验证器是否仅限于作为次要因素，结合您拥有的东西和您知道的东西。		o	✓	308	5.2.3

V2.9 加密软件和设备验证程序要求

加密安全密钥是智能卡或 FIDO密钥，用户必须插入加密设备或将加密设备配对到计算机才能完成身份验证。验证程序向加密设备或软件发送质询 nonce，并且设备或软件根据安全存储的加密密钥计算响应。

单因素加密设备和软件以及多因素加密设备和软件的要求是相同的，因为对加密验证器的验证证明了对身份验证因素的占有。

#	描述	L2	L3	CWE	NIST §
2.9.1	验证中使用的加密密钥是否安全存储并受到保护，防止泄露，例如使用受信任的平台模块（TPM）或硬件安全模块（HSM）或可使用此安全存储的 OS 服务。	✓	✓	320	5.1.7.2
2.9.2	验证质询 nonce 的长度至少为 64 位，并且在加密设备的生命周期内具有统计上唯一或唯一。	✓	✓	330	5.1.7.2
2.9.3	验证在生成、种子设定和验证中使用了已批准的加密算法。	✓	✓	327	5.1.7.2

V2.10 服务身份验证要求

此部分不可穿透测试，因此没有任何 L1要求。但是，如果在体系结构、编码或安全代码评审中使用，请假定软件（就像 Java 密钥存储一样）是 L1 的最低要求。在任何情况下都不能接受明文存储机密。

#	描述	L2	L3	CWE	NIST §
2.10.1	验证服务内机密不依赖于不变的凭据，如密码、API 密钥或具有特权访问权限的共享帐户。	OS assisted	HSM	287	5.1.1.1
2.10.2	验证服务身份验证是否需要密码，且使用的服务帐户不是默认凭据。 (e.g. root/root or admin/admin 某些服务在安装过程中为默认值).	OS assisted	HSM	255	5.1.1.1
2.10.3	验证密码是否具有足够的保护，以防止脱机恢复攻击，包括本地系统访问。	OS assisted	HSM	522	5.1.1.1
2.10.4	验证密码、与数据库和第三方系统的集成、种子和内部机密以及 API 密钥都得到安全管理，不包括在源代码中或存储在源代码存储库中。此类存储应抵御脱机攻击。建议使用安全软件密钥存储（L1）、硬件 TPM 或 HSM （L3）进行密码存储。	OS assisted	HSM	798
术语表术语	意义
CSP	凭据服务提供商也称为标识提供程序
Authenticator	对密码、令牌、MFA、联合断言等进行身份验证的代码。
Verifier	核实用户身份的实体，利用认证协议核实用户身分拥有和控制一个或两个认证器。为此，核查者可能还需要验证将验证器与用户身份识别器联系起来的凭证，并检查其状态。
OTP	一次性密码
SFA	单因素身份验证器，例如您知道的东西（记住的秘密、密码、密码、PIN）、您拥有的东西（生物识别、指纹、面部扫描）或您拥有的东西（OTP 令牌、加密设备（如智能卡））、
MFA	多重身份验证，包括两个或多个单个因素

参考文献

有关详细信息，请参阅：

V3: 会话管理验证要求

控制目标

任何基于 Web 的应用程序或有状态 API的核心组件之一是它控制和维护用户或设备与它交互的状态的机制。会话管理将无状态协议更改为"有状态"，这对于区分不同的用户或设备至关重要。

确保经过验证的应用程序满足以下高级会话管理要求：

会话对每个人是唯一的，无法猜测或共享。
当不再需要会话时，会话将失效，并在不活动期间超时。

如前所述，这些要求已作了调整，以符合选定的NIST 800-63b控制措施的子集，重点是常见的威胁和常被利用的认证弱点。以前的核查要求已被淘汰、取消，或在大多数情况下进行了调整，以便与NIST 800-63b强制性要求的意图紧密结合。

安全验证要求

V3.1 基本会话管理要求 #	描述	L1	L2	L3	CWE	NIST §
3.1.1	验证应用程序从不在 URL 参数中显示会话令牌。	✓	✓	✓	598
V3.2 会话绑定要求 #	描述	L1	L2	L3	CWE	NIST §
3.2.1	验证应用程序在用户身份验证时生成新的会话令牌。	✓	✓	✓	384	7.1
3.2.2	验证会话令牌是否至少具有 64 位。	✓	✓	✓	331	7.1
3.2.3	验证应用程序仅使用安全方法（如适当的安全 Cookie（请参阅第 3.4 节）或 HTML 5 会话存储等在浏览器中存储会话令牌。	✓	✓	✓	539	7.1
3.2.4	验证会话令牌是使用批准的加密算法生成的。		✓	✓	331	7.1

对于会话管理，TLS 或其他安全传输通道是必需的。这一部分在"通信安全"章节中介绍。

V3.3 会话注销和超时要求

会话超时与 NIST 800-63保持一致，它允许比安全标准通常允许的会话超时时间长得多。组织应查看下表，如果根据应用程序的风险需要较长的超时时间，则 NIST 值应是会话空闲超时的上限。

在此背景下，L1 为 IAL1/AAL1，L2 为 IAL2/AAL3，L3 为 IAL3/AAL3。对于 IAL2/AAL2 和 IAL3/AAL3，较短的空闲超时是注销或重新验证以恢复会话的空闲时间的下限。

#	描述	L1	L2	L3	CWE	NIST §
3.3.1	验证注销和过期会使会话令牌无效，以便后退按钮或下游依赖方不会恢复经过身份验证的会话，包括跨依赖方。	✓	✓	✓	613	7.1
3.3.2	如果身份验证器允许用户保持登录状态，请验证在主动使用时或空闲期间之后定期进行重新身份验证。	30 days	12 hours or 30 minutes of inactivity, 2FA optional	12 hours or 15 minutes of inactivity, with 2FA	613	7.2
3.3.3	验证应用程序是否提供在成功更改密码后终止所有其他活动会话的选项（包括通过密码重置/恢复进行更改），以及这在应用程序、联合登录（如果存在）以及任何依赖方中有效。		✓	✓	613
3.3.4	验证用户是否能够查看并重新输入登录凭据，注销任何或所有当前活动会话和设备。		✓	✓	613	7.1

V3.4 基于 Cookie 的会话管理

#	描述	L1	L2	L3	CWE	NIST §
3.4.1	验证基于 Cookie 的会话令牌是否具有 'Secure' 属性集。	✓	✓	✓	614	7.1.1
3.4.2	验证基于 Cookie 的会话令牌是否具有"HttpOnly"属性集。	✓	✓	✓	1004	7.1.1
3.4.3	验证基于 Cookie 的会话令牌是否使用"Samesite"属性来限制跨站点请求伪造攻击的风险。	✓	✓	✓	16	7.1.1
3.4.4	验证基于 Cookie 的会话令牌是否使用"__Host-"前缀（请参阅引用）来提供会话 Cookie 的机密性。	✓	✓	✓	16	7.1.1
3.4.5	验证如果应用程序在域名下发布，以及设置或使用可能覆盖或披露会话 Cookie 的会话 Cookie 的其他应用程序，请使用尽可能精确的路径在基于 Cookie 的会话令牌中设置路径属性。	✓	✓	✓	16	7.1.1

V3.5 基于令牌的会话管理

基于令牌的会话管理包括 JWT、OAuth、SAML 和 API 密钥。其中，API 密钥已知较弱，不应用于新代码。

#	描述	L2	L3	CWE	NIST §
3.5.1	验证应用程序允许用户撤销与链接的应用程序建立信任关系的 OAuth 令牌。	✓	✓	290	7.1.2
3.5.2	验证应用程序使用会话令牌而不是静态 API 机密和密钥，但旧实现除外。	✓	✓	798
3.5.3	验证无状态会话令牌是否使用数字签名、加密和其他对策来防止篡改、包围、重播、空密码和密钥替换攻击。	✓	✓	345

V3.6 重新认证联合身份验证或断言

本节涉及编写依赖方（RP）或凭据服务提供商（CSP）代码的那些。如果依赖于实现这些功能的代码，请确保这些问题得到正确处理。

#	描述	L1	L2	L3	CWE	NIST §
3.6.1	验证依赖方是否指定凭据服务提供商（CSP）的最大身份验证时间，以及如果订阅者在该期间内没有使用会话，则 CSP 是否重新对订阅者进行身份验证。			✓	613	7.2.1
3.6.2	验证凭据服务提供商（CSP）是否将上次身份验证事件通知依赖方（RP），以允许 RP 确定是否需要重新验证用户。			✓	613	7.2.1

V3.7 防御会话管理漏洞

会话管理攻击很少，有些与会话的用户体验（UX）相关。以前，根据 ISO 27002 要求，ASVS需要同时阻塞多个会话。阻止同时进行会话不再合适，不仅因为现代用户拥有许多设备或应用是一个没有浏览器会话的 API，而且在大多数这些实现中，最后一个身份验证器获胜，这通常是攻击者。本节提供有关使用代码阻止、延迟和检测会话管理攻击的主要指导。

半开攻击的描述

2018年初，一些金融机构使用攻击者所谓的"半开放式攻击"遭到破坏。这个词一直停留在这个行业。攻击者袭击了具有不同专有代码库的多个机构，而且在同一机构中似乎有不同的代码库。半开放攻击利用了许多现有身份验证、会话管理和访问控制系统中常见的设计模式缺陷。

攻击者通过尝试锁定、重置或恢复凭据来启动半开放攻击。一种流行的会话管理设计模式，在未经身份验证、半经过半身份验证（密码重置、忘记用户名）和完全经过身份验证的代码之间重新使用用户配置文件会话对象/模型。此设计模式填充包含受害者配置文件的有效会话对象或令牌，包括密码哈希和角色。如果控制器或路由器中的访问控制检查无法正确验证用户是否已完全登录，则攻击者将能够充当用户。攻击可能包括将用户的密码更改为已知值、更新电子邮件地址以执行有效的密码重置、禁用多重身份验证或注册新的 MFA 设备、显示或更改 API 密钥等。

#	描述	L1	L2	L3	CWE	NIST §
3.7.1	在允许任何敏感事务或帐户修改之前，验证应用程序可确保完整、有效的登录会话或需要重新身份验证或辅助验证。	✓	✓	✓	306

参考文献

有关详细信息，请参阅:

V4：访问控制验证要求

控制目标

授权是只允许那些允许使用这些资源的人访问资源的概念。确保经过验证的应用程序满足以下高级要求:

访问资源的用户持有有效的凭据。.
用户与一组定义良好的角色和特权关联.
角色和权限元数据受到保护，防止重播或篡改.

安全验证要求

V4.1 通用访问控制设计

#	描述	L1	L2	L3	CWE
4.1.1	验证应用程序是否对受信任的服务层强制实施访问控制规则，尤其是在存在客户端访问控制且可以绕过时。	✓	✓	✓	602
4.1.2	验证访问控制使用的所有用户和数据属性以及策略信息不能由最终用户操作，除非特别授权。	✓	✓	✓	639
4.1.3	验证存在最特权原则 - 用户只能访问具有特定权限的功能、数据文件、URL、控制器、服务和其他资源。这意味着防止欺骗和提升特权。	✓	✓	✓	285
4.1.4	验证默认存在拒绝原则，即新用户/角色以最小或无权限启动，并且用户/角色在明确分配访问权限之前不会收到对新功能的访问权限。	✓	✓	✓	276
4.1.5	验证访问控制是否安全失效，包括发生异常时。	✓	✓	✓	285

V4.2 操作级访问控制

#	描述	L1	L2	L3	CWE
4.2.1	验证敏感数据和 API 是否受到保护，防止针对创建、读取、更新和删除记录的不安全直接对象引用（IDOR）攻击，例如创建或更新其他人的记录、查看每个人的记录或删除所有记录。	✓	✓	✓	639
4.2.2	验证应用程序或框架是否强制实施强大的反 CSRF 机制来保护经过身份验证的功能，并且有效的反自动化或反 CSRF 可保护未经身份验证的功能。	✓	✓	✓	352

V4.3 其他访问控制注意事项

#	描述	L1	L2	L3	CWE
4.3.1	验证管理接口使用适当的多重身份验证以防止未经授权的使用。	✓	✓	✓	419
4.3.2	验证目录浏览是否禁用，除非有意需要。此外，应用程序不应允许发现或披露文件或目录元数据，如 Thumbs.db, .DS_Store, .git or .svn folders.	✓	✓	✓	548
4.3.3	核实应用程序对价值较低的系统有额外的授权(如升级或自适应认证)，对价值较高的应用程序有额外的授权(如升级或自适应认证)，对价值较高的应用程序有额外的授权(如升级或自适应认证)，以根据应用程序的风险和过去的欺诈行为实施反欺诈控制。		✓	✓	732

参考文献

有关详细信息，请参阅:

V5：编码验证要求

控制目标

最常见的 Web应用程序安全漏洞是，在直接使用来自客户端或环境的输入时，在没有任何输出编码的情况下，无法正确验证输入。此弱点导致 Web 应用程序中几乎所有重大漏洞，例如跨站点脚本（XSS）、SQL注入、解释器注入、locale/Unicode 攻击、系统文件攻击和缓冲区溢出。

确保经过验证的应用程序满足以下高级要求：

输入验证和输出编码体系结构具有一个商定的管道，以防止注入攻击。
输入数据经过强类型、验证、范围或长度检查，或在最坏的情况下进行禁止或筛选。
输出数据根据尽可能靠近解释器的数据上下文进行编码或转义。

在现代 Web应用程序体系结构中，输出编码比以往任何时候都重要。在某些情况下很难提供健壮的输入验证，因此使用更安全的 API（如参数化查询、自动转义模板框架或精心挑选的输出编码）对应用程序的安全性至关重要。

V5.1 输入验证要求

正确实现的输入验证控制，使用允许列表和强数据类型，可以消除超过 90% 的所有注入攻击。长度和范围检查可以进一步减少这种情况。在应用程序体系结构、设计、编码以及单元和集成测试期间，需要构建安全输入验证。尽管许多这些项目在渗透测试中找不到，但未实现它们的结果通常存在于 V5.3 -输出编码和注入防护要求中。建议开发人员和安全代码审阅者将本节视为所有项目所需的L1 以防止注入。

#	描述	L1	L2	L3	CWE
5.1.1	验证应用程序是否具有针对 HTTP 参数污染攻击的防御能力，特别是当应用程序框架对请求参数的来源（GET、POST、cookie、headers或环境变量）没有区别时。	✓	✓	✓	235
5.1.2	验证框架是否防止大规模参数分配攻击，或者应用程序是否具有防止不安全参数分配（如标记private或类似字段）的对策。	✓	✓	✓	915
5.1.3	验证所有输入（HTML 表单字段、REST 请求、URL 参数、HTTP 标头、Cookie、批处理文件、RSS 源等）是否都使用正验证（允许列表）进行验证。	✓	✓	✓	20
5.1.4	验证结构化数据是否针对定义的架构（包括允许的字符、长度和模式）进行强类型化和验证（例如信用卡号或电话），或验证两个相关字段是否合理，例如检查郊区和邮政编码是否匹配）。	✓	✓	✓	20
5.1.5	验证 URL 重定向和转发只允许显示在允许列表中的目标，或在重定向到可能不受信任的内容时显示警告。	✓	✓	✓	601

V5.2 沙盒要求

#	描述	L1	L2	L3	CWE
5.2.1	验证所有来自WYSIWYG编辑器或类似的不受信任的HTML输入都已经用HTML sanitizer库或框架功能进行了适当的安全检查。	✓	✓	✓	116
5.2.2	验证非结构化数据是否经过安全检查，以执行允许字符和长度等安全措施。	✓	✓	✓	138
5.2.3	在传递到邮件系统之前，请验证应用程序是否对用户输入进行安全检查，以防止 SMTP 或 IMAP 注入。	✓	✓	✓	147
5.2.4	验证应用程序是否避免使用 eval（）或其他动态代码执行功能。如果没有替代方案，则在执行之前必须对包含的任何用户输入进行安全检查或沙盒处理。	✓	✓	✓	95
5.2.5	通过确保包含的任何用户输入已安全检查或沙盒，验证应用程序是否防止模板注入攻击。	✓	✓	✓	94
5.2.6	通过验证或隔离不受信任的数据或 HTTP 文件元数据（如文件名和 URL 输入等字段）来验证应用程序是否防止 SSRF 攻击。	✓	✓	✓	918
5.2.7	验证应用程序是否对用户提供的可扩展矢量图形（SVG）脚本内容进行安全检查、禁用或沙盒，特别是它们与内联脚本和异用对象生成的 XSS 相关内容。	✓	✓	✓	159
5.2.8	验证应用程序是否对用户提供的可执行脚本或表达式模板语言内容进行安全检查、禁用或沙盒，如Markdown, CSS or XSL stylesheets, BBCode, or similar.	✓	✓	✓	94

V5.3 输出编码和注入防护要求

与使用中的解释器接近或相邻的输出编码对任何应用程序的安全性都至关重要。通常，输出编码不会持久化，而是用于在适当的输出上下文中使输出安全，供立即使用。输出编码失败将导致应用程序不安全、可注入和不安全。

#	描述	L1	L2	L3	CWE
5.3.1	验证输出编码是否与所需的解释器和上下文相关。例如，根据上下文要求，专门使用 HTML 值、HTML 属性、JavaScript、URL 参数、HTTP 标头、SMTP 和其他其他编码器，尤其是来自不受信任的输入 (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara).	✓	✓	✓	116
5.3.2	验证输出编码是否保留用户选择的字符集和区域设置，以便任何 Unicode 字符点都有效且安全处理.	✓	✓	✓	176
5.3.3	验证上下文联系（最好是自动的，或者最坏的情况是手动的）输出转义可防止反射、存储和基于 DOM 的 XSS。	✓	✓	✓	79
5.3.4	验证数据选择或数据库查询（例如 .SQL、HQL、ORM、NoSQL）是否使用参数化查询、ORM、实体框架，或以其他方式受到保护，免受数据库注入攻击。	✓	✓	✓	89
5.3.5	验证不存在参数化或更安全的机制的地方，使用特定于上下文的输出编码来防止注入攻击，例如使用 SQL 转义来防止 SQL 注入。	✓	✓	✓	89
5.3.6	验证应用程序是否防止 JavaScript 或 JSON 注入攻击，包括 eval 攻击、远程 JavaScript 包括、内容安全策略（CSP）绕过、DOM XSS 和 JavaScript 表达式评估。	✓	✓	✓	830
5.3.7	验证应用程序是否防止 LDAP 注入漏洞，或者是否实施了防止 LDAP 注入的特定安全控制。	✓	✓	✓	90
5.3.8	验证应用程序是否防止 OS 命令注入，以及操作系统调用是否使用参数化的 OS 查询或使用上下文命令行输出编码。	✓	✓	✓	78
5.3.9	验证应用程序是否防止本地文件包含（LFI）或远程文件包含（RFI）攻击。	✓	✓	✓	829
5.3.10	验证应用程序是否防止 XPath 注入或 XML 注入攻击。	✓	✓	✓	643

注意：使用参数化查询或转义 SQL 并不总是足够的;表和列名称、ORDER BY 等无法转义。在这些字段中包含转义用户提供的数据会导致查询失败或 SQL 注入。

注意：SVG 格式显式允许几乎所有上下文中的 ECMA 脚本，因此可能无法完全阻止所有 SVG XSS 向量。如果需要 SVG 上传，我们强烈建议将这些上传的文件作为text/plain提供，或者使用其他用户提供的内容域，以防止 XSS 成功接管应用程序。

V5.4 内存、字符串和非托管代码要求

以下要求仅在应用程序使用系统语言或非托管代码时适用。

#	描述	L2	L3	CWE
5.4.1	验证应用程序是否使用内存安全字符串、更安全的内存副本和指针算术来检测或防止堆栈、缓冲区溢出。	✓	✓	120
5.4.2	验证格式字符串不会接受潜在的恶意输入，并且是恒定的。	✓	✓	134
5.4.3	验证符号、范围和输入验证技术是否用于防止整数溢出。	✓	✓	190

V5.5 反序列化预防要求

#	描述	L1	L2	L3	CWE
5.5.1	验证序列化对象是否使用完整性检查或加密以防止恶意对象创建或数据篡改。	✓	✓	✓	502
5.5.2	验证应用程序是否正确地将 XML 解析器限制为仅使用尽可能限制最严格的配置，并确保禁用不安全功能（如解析外部实体）以防止 XML eXternal 实体（XXE）攻击。	✓	✓	✓	611
5.5.3	验证在自定义代码和第三方库（如 JSON、XML 和 YAML 解析器）中是否避免或保护不受信任的数据的反序列化。	✓	✓	✓	502
5.5.4	验证在浏览器或基于 JavaScript 的后端中分析 JSON 时，JSON.parse 是否用于分析 JSON 文档。不要使用 eval（）来分析 JSON。	✓	✓	✓	95

参考文献

有关详细信息，请参阅:

For more information on auto-escaping, please see:

For more information on deserialization, please see:

V6：存储的加密验证要求

控制目标

确保经过验证的应用程序满足以下高级要求：

所有加密模块都以安全的方式失效，并且错误得到正确处理。
使用合适的随机数生成器。
对密钥的访问得到安全管理。

V6.1 数据分类

最重要的资产是应用程序处理、存储或传输的数据。始终执行隐私影响评估，以正确分类任何存储数据的数据保护需求。

#	描述	L2	L3	CWE
6.1.1	验证受监管的私人数据在静止状态下是否加密存储，例如个人身份信息（PII）、敏感个人信息或评估可能受欧盟 GDPR 影响的数据。	✓	✓	311
6.1.2	验证受监管的健康数据在静止状态是否加密存储，例如医疗记录、医疗设备详细信息或非匿名研究记录。	✓	✓	311
6.1.3	验证受监管的财务数据在静止状态下是否加密存储，如财务账户、违约或信用记录、税务记录、支付历史记录、受益人或非匿名市场或研究记录。	✓	✓	311

V6.2 算法

最近加密技术的进步意味着以前安全的算法和密钥长度不再安全或足以保护数据。因此，应该可以更改算法。

尽管此部分不容易进行渗透测试，但开发人员应该将整个部分视为必填项，即使大多数项目都缺少L1

#	描述	L1	L2	L3	CWE
6.2.1	验证所有加密模块是否安全失效，并且错误的处理方式不会启用填充攻击。	✓	✓	✓	310
6.2.2	验证是否使用经过行业验证或政府批准的加密算法、模式和库，而不是自定义编码加密。		✓	✓	327
6.2.3	验证加密初始化矢量、密码配置和块模式是否使用最新建议安全配置。		✓	✓	326
6.2.4	验证随机数、加密或散列算法、密钥长度、圆段、密码或模式可随时重新配置、升级或交换，以防止加密中断。		✓	✓	326
6.2.5	验证已知不安全的块模式 (i.e. ECB, etc.), 填充模式 (i.e. PKCS#1 v1.5, etc.), 区块加密(i.e. Triple-DES, Blowfish, etc.), 和弱散列算法 (i.e. MD5, SHA1, etc.) 除非向后兼容性需要，否则不使用.		✓	✓	326
6.2.6	验证非密码、初始化矢量和其他单一使用编号不得与给定的加密密钥一次使用。生成方法必须适用于使用的算法。		✓	✓	326
6.2.7	验证加密数据是否通过签名、经过身份验证的密码模式或 HMAC 进行身份验证，以确保未授权方不会更改密码文本。			✓	326
6.2.8	验证所有加密操作都是恒定的，在比较、计算或返回时没有"短路"操作，以避免信息泄露。			✓	385

V6.3 随机值

真正的伪随机数生成(PRNG)是非常难搞好的。一般来说，如果过度使用，系统内cpu会很快耗尽，但随机性较低的cpu消耗会导致可预测的密钥和秘密。

#	描述	L2	L3	CWE
6.3.1	验证当攻击者预期这些随机值不可猜测时，是否使用加密模块批准的加密安全随机数生成器生成所有随机数、随机文件名、随机 GUID 和随机字符串。	✓	✓	338
6.3.2	验证使用 GUID v4 算法和加密安全的伪随机数生成器（CSPRNG）创建随机 GUID。使用其他伪随机数生成器创建的 GUID 可能是可预测的。	✓	✓	338
6.3.3	验证即使应用程序负载很重，也要使用适当的位创建随机数，或者应用程序在这种情况下会正常降级。		✓	338

V6.4 密钥管理

尽管此部分不容易进行渗透测试，但开发人员应该将整个部分视为必填项，即使大多数项目都缺少L1。

#	描述	L1	L2	L3	CWE
6.4.1	验证密钥保管库等机密管理解决方案是否用于安全地创建、存储、控制对机密的访问和销毁。		✓	✓	798
6.4.2	验证密钥材料是否未向应用程序公开，而是使用隔离的安全模块（如保管库）进行加密操作。		✓	✓	320

参考文献

有关详细信息，请参阅:

V7：错误处理和日志记录验证要求

控制目标

错误处理和日志记录的主要目标是为用户、管理员和事件响应团队提供有用的信息。目标不是创建大量的日志，而是高质量的日志。

高质量的日志通常包含敏感数据，必须根据当地数据隐私法律或指令进行保护。这应包括：

除非特别需要，否则不收集或记录敏感信息。
确保所有记录的信息都按照其数据分类得到安全处理和保护。
确保日志不会永远存储，但绝对的生存期尽可能短。

如果日志包含私有或敏感数据，其定义因国家/地区而异，则日志将成为应用程序持有的一些最敏感信息，因此对攻击者本身非常有吸引力。

同样重要的是确保应用程序安全失效，并且错误不会泄露不必要的信息。

V7.1 日志内容要求

记录敏感信息是危险的--日志本身就会成为机密，这意味着它们需要加密，成为保留政策的对象，并且必须在安全审计中披露。确保日志中只保留必要的信息，当然不能保留付款、凭证（包括会话令牌）、敏感或个人身份信息。

V7.1 涵盖 OWASP 前 10 名 2017：A10.由于 2017：A10 和本节不可渗透测试，因此对以下内容非常重要：

开发人员确保完全遵守本节，就像所有项目都标记为 L1 一样
渗透测试人员通过访谈、屏幕截图或断言验证 V7.1 中所有项目的完全合规性

#	描述	L1	L2	L3	CWE
7.1.1	验证应用程序未记录凭据或付款详细信息。会话令牌应仅存储在不可逆的哈希窗体中的日志中。	✓	✓	✓	532
7.1.2	验证应用程序是否未记录当地隐私法或相关安全策略定义的其他敏感数据。	✓	✓	✓	532
7.1.3	验证应用程序是否记录安全相关事件，包括成功和失败的身份验证事件、访问控制失败、反序列化失败和输入验证失败。		✓	✓	778
7.1.4	验证每个日志事件是否包含必要的信息，这些信息允许在发生事件时详细调查时间线。		✓	✓	778

V7.2 日志处理要求

及时日志记录对于审核事件、会审和上报至关重要。确保应用程序的日志清晰，并且可以轻松地在本地监视和分析或将日志传输到远程监控系统。

V7.2 涵盖 OWASP 前 10 名 2017：A10.由于 2017：A10 和本节不可渗透测试，这对于:

开发人员确保完全遵守本节，就像所有项目都标记为 L1 一样
渗透测试人员通过访谈、屏幕截图或断言验证 V7.2 中所有项目的完全合规性

#	描述	L1	L2	L3	CWE
7.2.1	验证是否记录了所有身份验证决策，而不存储敏感的会话令牌或密码。这应包括具有安全调查所需的相关元数据的请求。		✓	✓	778
7.2.2	验证是否可以记录所有访问控制决策并记录所有失败的决策。这应包括具有安全调查所需的相关元数据的请求。		✓	✓	285

V7.3 日志保护要求

可以简单修改或删除的日志对调查和起诉毫无用处。日志的披露可以公开有关应用程序或它包含的数据的内部详细信息。保护日志免遭未经授权的披露、修改或删除时，必须小心。

#	描述	L2	L3	CWE
7.3.1	验证应用程序是否对用户提供的数据进行适当编码，以防止日志注入。	✓	✓	117
7.3.2	在日志查看软件中查看所有事件时，请验证所有事件是否受到保护，防止其注入。	✓	✓	117
7.3.3	验证安全日志是否受到保护，防止未经授权的访问和修改。	✓	✓	200
7.3.4	验证时间源是否同步到正确的时间和时区。如果系统是全局的，以帮助进行事件后取证分析，请考虑仅在 UTC 中进行日志记录。	✓	✓

注意：使用自动动态工具和渗透测试很难测试和审查日志编码（7.3.1），但架构师、开发人员和源代码审阅者应认为这是 L1 要求。

V7.4 错误处理

错误处理的目的是允许应用程序提供安全相关事件，以便监视、会审和上报。目的不是创建日志。在记录与安全相关的事件时，请确保日志具有目的，并且可以通过 SIEM 或分析软件来区分它。

#	描述	L1	L2	L3	CWE
7.4.1	验证在发生意外或安全敏感错误时是否显示通用消息，可能具有支持人员可用于调查的唯一 ID。	✓	✓	✓	210
7.4.2	验证异常处理（或功能等效项）是否用于整个代码库，以考虑预期和意外的错误条件。		✓	✓	544
7.4.3	验证是否定义了"最后一个方法"错误处理程序，该处理程序将捕获所有未处理的异常。		✓	✓	431

注意：某些语言（如 Swift 和Go）以及通过常见的设计实践-许多功能语言不支持异常或最后一个命令事件处理程序。在这种情况下，架构师和开发人员应使用模式、语言或框架友好的方式，以确保应用程序能够安全地处理异常、意外或与安全相关的事件。

参考文献

有关详细信息，请参阅:

V8：数据保护验证要求

控制目标

健全数据保护有三个关键要素：机密性、完整性和可用性（CIA）。此标准假定数据保护在受信任的系统（如服务器）上实施，该系统已过硬，并有足够的保护。

应用程序必须假定所有用户设备都受到某种影响。如果应用程序在不安全的设备（如共享计算机、手机和平板电脑）上传输或存储敏感信息，则应用程序负责确保这些设备上存储的数据经过加密，并且不会轻易非法获取、更改或披露。

确保经过验证的应用程序满足以下高级别数据保护要求：

保密性：在传输过程中和存储时，应保护数据免受未经授权的观察或披露。
完整性：应保护数据不被未经授权的攻击者恶意创建、更改或删除。
可用性：数据应可根据要求提供给授权用户。

V8.1 一般数据保护

#	描述	L2	L3	CWE
8.1.1	验证应用程序可防止敏感数据缓存在服务器组件（如负载均衡器和应用程序缓存）中。	✓	✓	524
8.1.2	验证服务器上存储的敏感数据的所有缓存或临时副本在授权用户访问敏感数据后是否受到保护，防止未经授权的访问或清除/失效。	✓	✓	524
8.1.3	验证应用程序最小化请求中的参数数，如隐藏字段、Ajax 变量、cookie 和标头值。	✓	✓	233
8.1.4	验证应用程序能否检测和提醒异常请求数，例如 IP、用户、每小时或每天的总数，或者任何对应用程序有意义的请求。	✓	✓	770
8.1.5	验证是否执行了重要数据的定期备份，以及是否执行了数据测试还原。		✓	19
8.1.6	验证备份是否安全存储，以防止数据被盗或损坏。		✓	19

V8.2 客户端数据保护

#	描述	L1	L2	L3	CWE
8.2.1	验证应用程序设置足够的反缓存标头，以便敏感数据不会缓存在现代浏览器中。	✓	✓	✓	525
8.2.2	验证存储在浏览器存储中的数据（如 HTML5 本地存储、会话存储、IndexedDB 或 Cookie）不包含敏感数据或 PII。	✓	✓	✓	922
8.2.3	验证在客户端或会话终止后，是否从客户端存储（如浏览器 DOM）清除了经过身份验证的数据。	✓	✓	✓	922

V8.3 敏感私有数据

本节有助于保护敏感数据不被创建、读取、更新或删除，尤其是批量数据。

遵守本节意味着符合 V4 访问控制，特别是V4.2。例如，要防止未经授权的更新或泄露敏感的个人信息，需要遵守 V4.2.1。请遵守本节和 V4 的全覆盖。

注意：隐私法规和法律（如澳大利亚隐私原则 APP-11 或GDPR）直接影响应用程序必须如何实施敏感个人信息的存储、使用和传输。这从严厉的惩罚到简单的建议。请咨询您当地的法律和法规，并可根据要求咨询合格的隐私专家或律师。

#	描述	L1	L2	L3	CWE
8.3.1	验证敏感数据是否发送到 HTTP 消息正文或标头中的服务器，以及来自任何 HTTP 谓词的查询字符串参数不包含敏感数据。	✓	✓	✓	319
8.3.2	验证用户是否具有按需删除或导出数据的方法。	✓	✓	✓	212
8.3.3	验证用户是否获得有关收集和使用所提供的个人信息的清晰语言，以及用户在以任何方式使用这些数据之前已提供选择加入同意使用这些数据。	✓	✓	✓	285
8.3.4	验证应用程序创建和处理的所有敏感数据都已识别，并确保已制定有关如何处理敏感数据的政策。	✓	✓	✓	200
8.3.5	如果数据是根据相关数据保护指令收集的，或者需要记录访问情况，则验证访问敏感数据是否进行审核（而不记录敏感数据本身）。		✓	✓	532
8.3.6	使用零或随机数据，验证内存中包含的敏感信息在不再需要缓解内存转储攻击时是否被覆盖。		✓	✓	226
8.3.7	验证加密所需的敏感或私人信息是否使用具有保密性和完整性的已批准算法进行加密。		✓	✓	327
8.3.8	验证敏感个人信息是否受数据保留分类，以便自动删除旧数据或过期数据，按计划删除，或根据情况需要删除。		✓	✓	285

在考虑数据保护时，首要考虑的应该是批量提取、修改或过度使用。例如，许多社交媒体系统仅允许用户每天添加100 个新朋友，但这些请求来自哪个系统并不重要。银行平台可能希望阻止每小时超过5笔交易，将1000元以上的资金转移到外部机构。每个系统的要求可能大不相同，因此决定"异常"必须考虑威胁模型和业务风险。重要的标准是能够检测、阻止或最好阻止此类异常批量操作。

参考文献

有关详细信息，请参阅:

V9：通信验证要求

控制目标

确保经过验证的应用程序满足以下高级别要求：

无论传输的数据是否敏感，始终使用 TLS 或强加密
最新的、领先的配置，建议用于采用首选算法和密码。
弱或即将被弃用的算法和密码作为最后手段被采用。
已弃用或已知的不安全算法和密码将被禁用。

关于安全TLS配置的领先行业建议经常变化，通常是由于现有算法和密码的灾难性突破。始终使用最新版本的TLS配置审查工具（如SSLyze或其他TLS扫描器）来配置首选顺序和算法选择。应定期检查配置，以确保安全通信配置始终存在并有效。

V9.1 客户端通信安全要求

所有客户端通信应仅通过加密通信路径进行。特别是，使用TLS1.2或更晚基本上是所有，但要求现代浏览器和搜索引擎。应使用在线工具定期审查配置，以确保采用最新的领先做法。

#	描述	L1	L2	L3	CWE
9.1.1	验证安全 TLS 是否用于所有客户端连接，并且不会回退到不安全或未加密的协议。	✓	✓	✓	319
9.1.2	使用联机或最新的 TLS 测试工具验证是否启用了强算法、密码和协议，并设置了最强的算法和密码作为首选算法。	✓	✓	✓	326
9.1.3	验证旧版本的 SSL 和 TLS 协议、算法、密码和配置是否已禁用，例如 SSLv2、SSLv3 或 TLS 1.0 和 TLS 1.1。最新版本的 TLS 应该是首选的密码套件。	✓	✓	✓	326

V9.2 服务器通信安全要求

服务器通信不仅仅是HTTP。与其他系统之间的安全连接，如监控系统、管理工具、远程访问和ssh、中间件、数据库、主机、合作伙伴或外部源系统--必须到位。所有这些都必须进行加密，以免出现"日防夜防，家贼难防"的情形。

#	描述	L2	L3	CWE
9.2.1	验证与服务器的连接是否使用受信任的 TLS 证书。在使用内部生成或自签名证书时，必须将服务器配置为仅信任特定的内部 CA 和特定的自签名证书。所有其他应被拒绝。	✓	✓	295
9.2.2	验证加密通信（如 TLS）是否用于所有入站和出站连接，包括管理端口、监视、身份验证、API 或 Web 服务调用、数据库、云、无服务器、大型机、外部连接和合作伙伴连接。服务器不得回退到不安全或未加密的协议。	✓	✓	319
9.2.3	验证与涉及敏感信息或功能的外部系统的所有加密连接都经过身份验证。	✓	✓	287
9.2.4	验证是否已启用并配置正确的认证吊销，如联机证书状态协议（OCSP）。	✓	✓	299
9.2.5	验证是否已记录后端 TLS 连接故障.		✓	544

参考文献

有关详细信息，请参阅:

关于"TLS 的已批准模式"的注意事项。过去，ASVS 指的是美国标准 FIPS 140-2，但作为一个全球标准，应用美国标准可能很难、矛盾或令人困惑。实现 9.1.3 的更好方法是查看指南（如 Mozilla 的服务器端 TLS） or generate known good configurations或生成已知良好的配置，并使用已知的 TLS 评估工具（如 sslyze、各种漏洞扫描器或受信任的 TLS在线评估服务）获得所需的安全级别。一般来说，我们认为本节的不合规是使用过时或不安全的密码和算法、缺乏完美的正向保密、过时或不安全的 SSL 协议、弱的首选密码等等。

V10：恶意代码验证要求

控制目标

确保代码满足以下高级别要求：

恶意活动得到安全、妥善的处理，不会影响应用程序的其余部分.
没有定时炸弹或其他基于时间的攻击.
不请求到恶意或未经授权的目的地.
没有后门, Easter eggs, salami attacks, rootkits, 或攻击者可以控制的未经授权的代码。

查找恶意代码的行为是徒劳的，这是不可能完全验证的。应尽最大努力确保代码没有固有的恶意代码或不需要的功能。

V10.1 代码完整性控制

对抗恶意代码的最佳防御是"信任，但验证"。在许多司法管辖区，将未经授权的或恶意代码引入代码通常是刑事犯罪。政策和程序应明确有关恶意代码的制裁。

首席开发人员应定期查看代码签入，尤其是那些可能访问时间、I/O 或网络功能的代码签入。

#	描述	L1	L2	L3	CWE
10.1.1	验证正在使用的代码分析工具，该工具可以检测潜在的恶意代码，如时间函数、不安全的文件操作和网络连接。			✓	749

V10.2 恶意代码搜索

恶意代码极为罕见，难以检测。手动行代码审查可以帮助寻找逻辑炸弹，但即使是最有经验的代码审阅者将很难找到恶意代码，即使他们知道它的存在。

如果没有对源代码（包括第三方库）的完全访问，则无需遵守本节。

#	描述	L2	L3	CWE
10.2.1	验证应用程序源代码和第三方库不包含未经授权的电话家庭或数据收集功能。如果存在此类功能，则在收集任何数据之前获取用户操作的权限。	✓	✓	359
10.2.2	验证应用程序是否对隐私相关功能或传感器（如联系人、摄像机、麦克风或位置）不要求不必要的或过多的权限。	✓	✓	272
10.2.3	验证应用程序源代码和第三方库不包含后门，例如硬编码或其他未记录的帐户或密钥、代码混淆、未记录的二进制 Blob、rootkit 或反调试、不安全的调试功能，或者发现可能恶意使用的过时、不安全或隐藏功能。		✓	507
10.2.4	通过搜索日期和时间相关功能，验证应用程序源代码和第三方库不包含定时炸弹。		✓	511
10.2.5	验证应用程序源代码和第三方库不包含恶意代码，如salami attacks, logic bypasses, or logic bombs.		✓	511
10.2.6	验证应用程序源代码和第三方库不包含彩蛋或任何其他可能不需要的功能。		✓	507

V10.3 部署的应用程序完整性控制

部署应用程序后，仍然可以插入恶意代码。应用程序需要保护自己免受常见攻击，例如从不受信任的源执行未签名的代码和子域接管。遵守本部分可能是可操作且连续的。

#	描述	L1	L2	L3	CWE
10.3.1	验证如果应用程序具有客户端或服务器自动更新功能，应通过安全通道获取更新并进行数字签名。在安装或执行更新之前，更新代码必须验证更新的数字签名。	✓	✓	✓	16
10.3.2	验证应用程序是否使用完整性保护，如代码签名或子资源完整性。应用程序不得从不受信任的源加载或执行代码，例如从不受信任的源或 Internet 加载包括、模块、插件、代码或库。	✓	✓	✓	353
10.3.3	如果应用程序依赖于 DNS 条目或 DNS 子域（如过期的域名、过期的 DNS 指针或 CNAMEs、公共源代码存储库中的过期项目，或者临时云 API、无服务器函数或存储存储桶（自动存储桶autogen-bucket-idid.cloud.example.com）或类似文件，则验证应用程序是否具有从子域接管中免受保护。保护可以包括确保定期检查应用程序使用的 DNS 名称是否过期或更改。	✓	✓	✓	350

参考文献

V11：业务逻辑验证要求

控制目标

确保经过验证的应用程序满足以下高级别要求：

业务逻辑流是按顺序处理的，不能绕过。
业务逻辑包括检测和防止自动攻击的限制，例如连续小额资金转移，或一次添加一百万个好友，等等。
高价值业务逻辑流考虑了滥用案例和恶意参与者，并具有防止欺骗、篡改、拒绝、信息泄露和特权提升攻击的保护。

V11.1 业务逻辑安全要求

业务逻辑安全性对于每个应用程序都是个性化的，因此没有一个清单会全面符合要求。业务逻辑安全性必须设计为可防止可能的外部威胁 - 无法使用 Web 应用程序防火墙或安全通信添加业务逻辑安全性。我们建议在设计期间使用威胁建模，例如使用 OWASP Cornucopia 或类似工具。

#	描述	L1	L2	L3	CWE
11.1.1	验证应用程序将仅按顺序处理同一用户的业务逻辑流，而不跳过步骤。	✓	✓	✓	841
11.1.2	验证应用程序将只处理业务逻辑流，所有步骤都在现实的人类提交时间内处理，即交易不会太快提交。	✓	✓	✓	799
11.1.3	验证应用程序对特定业务操作或事务具有适当的限制，这些操作或事务是根据每个用户正确执行的。	✓	✓	✓	770
11.1.4	验证应用程序是否有足够的反自动化控制，以检测和防止数据泄露、业务逻辑请求过多、文件上传过多或拒绝服务攻击。	✓	✓	✓	770
11.1.5	验证应用程序是否具有业务逻辑限制或验证，以防止可能的业务风险或威胁，使用威胁建模或类似方法进行识别。	✓	✓	✓	841
11.1.6	验证应用程序是否受到"检查到使用时间"（TOCTOU）问题或其他敏感操作的竞赛条件的影响。		✓	✓	367
11.1.7	验证应用程序从业务逻辑的角度监控异常事件或活动。例如，尝试执行不按顺序的行动或正常用户绝不会尝试的行动		✓	✓	754
11.1.8	在检测到自动攻击或异常活动时，验证应用程序是否具有可配置的警报。		✓	✓	390

参考文献

有关详细信息，请参阅:

OWASP Web Security Testing Guide 4.1: Business Logic Testing
Anti-automation can be achieved in many ways, including the use of OWASP AppSensor and OWASP Automated Threats to Web Applications
OWASP AppSensor can also help with Attack Detection and Response.
OWASP Cornucopia

V12：文件和资源验证要求

控制目标

确保经过验证的应用程序满足以下高级别要求：

应以安全的方式相应地处理不受信任的文件数据。
从不受信任的源获取的不受信任的文件数据存储在 Web 根目录之外，并且权限有限。

V12.1 文件上传要求

虽然zip炸弹显然可以使用渗透测试技术进行测试，但它们被认为是L2及以上级别的，以鼓励设计和开发考虑与仔细的手动测试，并避免拒绝服务条件的自动或不熟练的手动渗透测试。

#	描述	L1	L2	L3	CWE
12.1.1	验证应用程序不会接受可能填满存储或导致拒绝服务的大型文件。	✓	✓	✓	400
12.1.2	验证压缩文件是否检查"zip 炸弹" - 小型输入文件，将解压缩成巨大的文件，从而耗尽文件存储限制。		✓	✓	409
12.1.3	验证每个用户的文件大小配额和最大文件数是否强制实施，以确保单个用户无法用过多的文件或过大的文件填满存储。		✓	✓	770

V12.2 文件完整性要求

#	描述	L1	L2	L3	CWE
12.2.1	验证从不受信任的源获取的文件是否根据文件的内容验证为预期类型。		✓	✓	434

V12.3 文件执行要求

#	描述	L1	L2	L3	CWE
12.3.1	验证系统或框架文件系统不直接使用用户提交的文件名元数据，以及 URL API 是否用于防止路径遍历。	✓	✓	✓	22
12.3.2	验证用户提交的文件名元数据是否经过验证或忽略，以防止披露、创建、更新或删除本地文件（LFI）.	✓	✓	✓	73
12.3.3	验证用户提交的文件名元数据是否经过验证或忽略，以防止通过远程文件包含（RFI）或服务器端请求伪造（SSRF）攻击披露或执行远程文件。	✓	✓	✓	98
12.3.4	通过验证或忽略 JSON、JSONP 或 URL 参数中的用户提交的文件名来验证应用程序是否防止反射文件下载（RFD），响应内容类型标头应设置为text/plain，并且内容处置标头应具有固定的文件名。	✓	✓	✓	641
12.3.5	验证不受信任的文件元数据是否直接用于系统 API 或库，以防止 OS 命令注入。	✓	✓	✓	78
12.3.6	验证应用程序是否包含并执行来自不受信任来源的功能，例如未经验证的内容发布网络、JavaScript库、node npm库或服务器端DLL。		✓	✓	829

V12.4 文件存储要求

#	描述	L1	L2	L3	CWE
12.4.1	验证从不受信任的源获取的文件是否存储在 Web 根目录之外，权限有限，最好具有强验证功能。	✓	✓	✓	922
12.4.2	验证防病毒扫描程序是否扫描从不受信任的源获取的文件，以防止上载已知的恶意内容。	✓	✓	✓	509

V12.5 文件下载要求

#	描述	L1	L2	L3	CWE
12.5.1	验证 Web 层是否配置为仅提供具有特定文件扩展名的文件，以防止意外信息和源代码泄漏。例如，备份文件（例如 .bak）、临时工作文件（例如.swp）、压缩文件（.zip、.tar.gz 等）和编辑人员常用的其他扩展名应被阻止，除非需要。	✓	✓	✓	552
12.5.2	验证对上载文件的直接请求永远不会作为 HTML/JavaScript 内容执行.	✓	✓	✓	434

V12.6 SSRF 保护要求

#	描述	L1	L2	L3	CWE
12.6.1	验证网络或应用程序服务器，是否配置了允许服务器向其发送请求或加载数据/文件的资源或系统列表	✓	✓	✓	918

参考文献

有关详细信息，请参阅:

V13: API 和 Web 服务验证要求

控制目标

确保使用受信任的服务层 API（通常使用 JSON 或 XML 或 GraphQL）的经过验证的应用程序具有：

充分身份验证、会话管理和授权所有 Web 服务。
输入从较低信任级别传递到更高信任级别的所有参数的输入验证。
所有 API 类型（包括云和无服务器 API）的有效安全控制

请结合同一级别的所有其他章节阅读本章;我们不再重复身份验证或 API 会话管理问题。

V13.1 通用Web服务安全验证要求

#	描述	L1	L2	L3	CWE
13.1.1	验证所有应用程序组件是否使用相同的编码和解析器，以避免分析利用 SSRF 和 RFI 攻击中可能使用的不同 URI 或文件分析行为的攻击。	✓	✓	✓	116
13.1.2	验证对管理和管理功能的访问是否仅限于授权的管理员。	✓	✓	✓	419
13.1.3	验证 API URL 不会公开敏感信息，如 API 密钥、会话令牌等。	✓	✓	✓	598
13.1.4	验证授权决策是在 URI 中做出的，由控制器或路由器的编程或声明性安全性强制实施，并在资源级别通过基于模型的权限强制实施。		✓	✓	285
13.1.5	验证包含意外或缺少内容类型的请求是否被拒绝了相应的标头（HTTP 响应状态 406 不可接受或 415 不支持的媒体类型）。		✓	✓	434

V13.2 REST 的 Web 服务验证要求

JSON 架构验证处于标准化的草稿阶段（请参阅参考）。在考虑使用 JSON 架构验证（这是 RESTful Web 服务的最佳做法）时，请考虑将以下附加数据验证策略与 JSON 架构验证结合使用：

分析 JSON 对象的验证，例如是否缺少或额外的元素。
使用标准输入验证方法（如数据类型、数据格式、长度等）验证 JSON 对象值。
和正式的 JSON 架构验证。

一旦 JSON 架构验证标准正式化，ASVS将更新其在此领域的建议。仔细监视任何正在使用的 JSON 架构验证库，因为它们需要定期更新，直到标准正式化，并且错误被修复为引用实现。

#	描述	L1	L2	L3	CWE
13.2.1	验证启用的 RESTful HTTP 方法是否为用户或操作的有效选择，例如防止正常用户在受保护的 API 或资源上使用 DELETE 或 PUT。	✓	✓	✓	650
13.2.2	在接受输入之前，请验证 JSON 架构验证是否到位并验证。	✓	✓	✓	20
13.2.3	验证使用 Cookie 的 RESTful Web 服务是否通过至少一项或多项以下操作受到保护，防止跨网站请求伪造：双重提交 Cookie 模式、CSRF 无项或源请求header检查。	✓	✓	✓	352
13.2.4	验证REST服务是否具有反自动控制功能，以防止过度调用，特别是在API未被认证的情况下。		✓	✓	770
13.2.5	验证 REST 服务是否显式检查传入的内容类型是否为预期内容类型，如 application/xml 或者 application/json.		✓	✓	436
13.2.6	验证消息头和有效负载是否可信，且在传输过程中未修改。在许多情况下，需要强加密传输（仅 TLS）可能就足够了，因为它同时提供机密性和完整性保护。每消息数数字签名可以在高安全性应用程序的传输保护之外提供额外的保证，但会带来额外的复杂性和风险，以权衡其优势。		✓	✓	345

V13.3 SOAP Web 服务验证要求

#	描述	L1	L2	L3	CWE
13.3.1	验证 XSD 架构验证是否进行，以确保正确格式的 XML 文档，然后验证每个输入字段，然后再对这些数据进行任何处理。	✓	✓	✓	20
13.3.2	验证是否使用 WS-Security 对消息有效负载进行签名，以确保客户端和服务之间的可靠传输。		✓	✓	345

注意：由于 XXE 攻击 DTD 的问题，不应使用 DTD 验证，并且框架 DTD 评估应根据 V14配置中的要求禁用。

V13.4 GraphQL 和其他 Web 服务数据层安全要求

#	描述	L1	L2	L3	CWE
13.4.1	验证查询是否允许列表或深度限制和数量限制的组合用于防止 GraphQL 或数据层表达式拒绝服务（DoS）。为避免昂贵的嵌套查询而发生，对于更高级的方案，应使用查询成本分析。		✓	✓	770
13.4.2	验证 GraphQL 或其他数据层授权逻辑应在业务逻辑层而不是 GraphQL 层实现。		✓	✓	285

引用

有关详细信息，请参阅:

V14: 配置验证要求

控制目标

确保经过验证的应用程序具有：

安全、可重复、可自动化的构建环境.
强化的第三方库、依赖项和配置管理，使应用程序不包括过期或不安全的组件。
按默认安全配置，因此管理员和用户必须削弱默认安全状态。

配置的应用开箱应该是安全上网的，也就是安全的开箱配置

V14.1 构建

构建流水线是可重复安全性的基础 - 每次发现不安全的东西时，都可以在源代码、生成或部署脚本中解析，并自动进行测试。我们强烈建议使用具有自动安全和依赖项检查的构建流水线，这些流水线会警告或破坏生成，以防止将已知的安全问题部署到生产环境中。不定期执行的手动步骤直接导致可避免的安全错误.

随着行业向 DevSecOps模型发展，确保部署和配置的持续可用性和完整性以实现"已知良好"状态非常重要。过去，如果系统被黑客攻击，需要几天到几个月的时间才能证明没有发生进一步的入侵。如今，随着软件定义的基础架构、零停机时间的快速A/B 部署和自动容器化构建的出现，可以自动和持续地构建、强化和部署任何受损系统的"已知良好"替代。

如果传统模式仍然存在，则必须采取手动步骤来强化和备份该配置，以便及时将受损的系统快速替换为高完整性、不折不扣的系统。

符合本节需要自动生成系统，并访问生成和部署脚本。

#	描述	L2	L3	CWE
14.1.1	验证应用程序生成和部署过程是否以安全和可重复的方式执行，例如 CI/ CD 自动化、自动配置管理和自动部署脚本。	✓	✓
14.1.2	验证编译器标志是否已配置为启用所有可用的缓冲区溢出保护和警告，包括堆栈随机化、数据执行预防，并在找到不安全的指针、内存、格式字符串、整数或字符串操作时中断生成。	✓	✓	120
14.1.3	验证服务器配置是否根据使用中的应用程序服务器和框架的建议进行强化。	✓	✓	16
14.1.4	验证可以使用自动部署脚本（在合理的时间内从记录和测试的 Runbook 构建）或及时从备份中还原应用程序、配置和所有依赖项进行重新部署。	✓	✓
14.1.5	验证授权管理员能否验证所有与安全相关的配置的完整性，以检测篡改情况。		✓

V14.2 依赖

依赖项管理对任何类型的应用程序的安全操作都至关重要。未能跟上过时或不安全的依赖关系，是迄今为止规模最大、成本最大的攻击的根本原因。

注意：在级别 1 中，14.2.1合规性与客户端和其他库和组件的观察或检测有关，而不是更准确的生成时间静态代码分析或依赖项分析。这些更准确的技术可以通过审查来发现。

#	描述	L1	L2	L3	CWE
14.2.1	验证所有组件都是最新的，最好在生成或编译期间使用依赖项检查器。	✓	✓	✓	1026
14.2.2	验证是否删除了所有不必要的功能、文档、示例、配置，例如示例应用程序、平台文档以及默认或示例用户。	✓	✓	✓	1002
14.2.3	如果应用程序资产（如 JavaScript 库、CSS 或 Web 字体）在内容交付网络（CDN）或外部提供商上外部托管，则子资源完整性（SRI）是否用于验证资产的完整性。	✓	✓	✓	829
14.2.4	验证第三方组件是否来自预定义、受信任和持续维护的存储库。		✓	✓	829
14.2.5	验证是否维护了所有正在使用的第三方库的清单目录。		✓	✓
14.2.6	验证通过沙盒或封装第三方库来仅向应用程序中公开所需的行为，可减少攻击面。		✓	✓	265

V14.3 意外的安全披露要求

生产用的配置应该进行加固，以防止常见的攻击，如调试控制台，提高跨站脚本(XSS)和远程文件包含(RFI)攻击的标准，并消除琐碎的信息发现 "漏洞"，这些漏洞是许多渗透测试报告不受欢迎的标志。这些问题中的许多问题很少被评为重大风险，因为它们与其他漏洞链在一起。如果这些问题在默认情况下不存在，就会在大多数攻击成功之前提高门槛。

#	描述	L1	L2	L3	CWE
14.3.1	验证 Web 或应用程序服务器和框架错误消息是否已配置为向用户提供可操作的自定义响应，以消除任何意外的安全披露。	✓	✓	✓	209
14.3.2	验证在生产环境中禁用 Web 或应用程序服务器和应用程序框架调试模式，以消除调试功能、开发人员控制台和意外的安全泄露。	✓	✓	✓	497
14.3.3	验证 HTTP 标头或 HTTP 响应的任何部分是否公开系统组件的详细版本信息。	✓	✓	✓	200

V14.4 HTTP Security Headers Requirements

#	描述	L1	L2	L3	CWE
14.4.1	验证每个HTTP响应都包含一个Content-Type头。text/*、/+xml和application/xml内容类型也应该指定一个安全的字符集（如UTF-8、ISO-8859-1）。	✓	✓	✓	173
14.4.2	验证所有API响应都包含Content-Disposition: attachment; filename="api.json "头（或内容类型的其他适当文件名）	✓	✓	✓	116
14.4.3	验证内容安全策略（CSP）响应标头是否到位，以帮助减轻对 XSS 攻击（如 HTML、DOM、JSON 和 JavaScript 注入漏洞）的影响。	✓	✓	✓	1021
14.4.4	验证所有响应都包含 X-Content-Type-Options: nosniff 标头。	✓	✓	✓	116
14.4.5	验证所有响应和所有子域都包含Strict-Transport-Security头，例如Strict-Transport-Security: max-age=15724800; includeSubdomains	✓	✓	✓	523
14.4.6	验证是否包含了合适的 "Referrer-Policy "头，如 "no-Referrer "或 " same-origin"。	✓	✓	✓	116
14.4.7	通过使用合适的Content-Security-Policy：frame-ancestors和X-Frame-Options响应头，验证Web应用程序的内容默认不能嵌入第三方网站，只有在必要时才允许嵌入确切的资源	✓	✓	✓	346

V14.5 验证HTTP请求标头要求

#	描述	L1	L2	L3	CWE
14.5.1	验证应用程序服务器是否只接受应用程序/API 使用的 HTTP 方法，包括预检前选项，以及记录/警报对应用程序上下文无效的任何请求。	✓	✓	✓	749
14.5.2	验证提供的源标头是否未用于身份验证或访问控制决策，因为攻击者可以很容易地更改源标头。	✓	✓	✓	346
14.5.3	验证跨源资源共享(CORS)Access-Control-Allow-Origin头使用严格的受信任域和子域的允许列表进行匹配，不支持 "null "origin。	✓	✓	✓	346
14.5.4	验证受信任代理或 SSO 设备（如承载令牌）添加的 HTTP 标头是否由应用程序进行身份验证。		✓	✓	306

参考文献

有关详细信息，请参阅:

OWASP Web Security Testing Guide 4.1: Testing for HTTP Verb Tampering
Adding Content-Disposition to API responses helps prevent many attacks based on misunderstanding on the MIME type between client and server, and the "filename" option specifically helps prevent Reflected File Download attacks.
Content Security Policy Cheat Sheet
Exploiting CORS misconfiguration for BitCoins and Bounties
OWASP Web Security Testing Guide 4.1: Configuration and Deployment Management Testing
Sandboxing third party components

附录 A：词汇表

Address Space Layout Randomization (ASLR) – 一种提高利用内存损坏漏洞难度的技术。
Allow list – 允许的数据或操作的列表，例如允许执行输入验证的字符列表.
Application Security – 应用层安全的重点是分析构成开放系统互连参考模型（OSI模型）应用层的组件，而不是关注底层操作系统或连接网络等。
Application Security Verification – 参照OWASP ASVS对程序进行技术评估。
Application Security Verification Report – 记录核查人员对某一特定应用的总体结果和辅助分析的报告。
Authentication – 核实申请用户所称的身份；
Automated Verification – 使用自动化工具（可以是动态分析工具，也可以是静态分析工具，或者两者兼而有之），利用漏洞签名来发现问题。
Black box testing – 它是一种软件测试方法，检查应用程序的功能，而不窥视其内部结构或工作原理。
Component – 一个自足的代码单元，带有与其他组件通信的相关磁盘和网络接口。
Cross-Site Scripting (XSS) – 通常在网络应用程序中发现的安全漏洞，允许在内容中注入客户端脚本。.
Cryptographic module – 实现加密算法和/或生成加密密钥的硬件、软件和/或固件。
Common Weakness Enumeration (CWE) -由社区制定的常见软件安全弱点清单。它是一种共同语言，是软件安全工具的衡量标准，也是弱点识别、缓解和预防工作的基线。
Design Verification – 对应用程序的安全架构进行技术评估。
Dynamic Application Security Testing (DAST) -技术的目的是检测表明应用程序在运行状态下存在安全漏洞的条件。
Dynamic Verification –使用自动化工具，利用漏洞签名来发现应用程序执行过程中的问题。
Fast IDentity Online (FIDO) - 一套认证标准，允许使用各种不同的认证方法，包括生物识别技术、可信平台模块（TPM）、USB安全令牌等。
Globally Unique Identifier (GUID) – 软件中作为标识符的唯一参考号
Hyper Text Transfer Protocol (HTTPS) –一种分布式、协作式、超媒体信息系统的应用协议。它是万维网数据通信的基础。
Hardcoded keys – 存储在文件系统中的加密密钥，无论是代码、注释还是文件。
Hardware Security Module (HSM) - 能够以受保护的方式存储加密密钥和其他秘密的硬件组件。Hibernate Query Language (HQL) - 一种查询语言，其外观与Hibernate ORM库使用的SQL类似。
Input Validation – 不受信任的用户输入的规范化和验证。
Malicious Code – 在应用程序的开发过程中，在应用程序所有者不知情的情况下引入应用程序的代码，从而规避了应用程序的预期安全策略。与病毒或蠕虫等恶意软件不同!
Malware – 在应用程序用户或管理员不知情的情况下，在运行时被引入应用程序的可执行代码
Open Web Application Security Project (OWASP) –开放式网络应用安全项目（OWASP）是一个全球性的免费开放社区，专注于提高应用软件的安全性。我们的使命是让应用程序的安全性 "可见"，以便人们和组织可以对应用程序的安全风险做出明智的决定。参见：https://www.owasp.org/
One-time Password (OTP) - 独一生成的密码，一次性使用。
Object-relational Mapping (ORM) - 用于允许在应用程序中使用与应用程序兼容的对象模型来引用和查询基于关系/表格的数据库的系统。
Password-Based Key Derivation Function 2 (PBKDF2) - 一种特殊的单向算法，用于从输入文本（如密码）和一个额外的随机盐值创建一个强密码密钥，因此，如果存储结果值而不是原始密码，可以用来使密码更难离线破解。
Personally Identifiable Information (PII) -是指可以单独使用或与其他信息一起使用的信息，以识别、联系或确定一个人的位置，或在背景下识别一个人
Position-independent executable (PIE) - 一段机器代码，放在主存储器的某处，无论其绝对地址如何，都能正常执行。
Public Key Infrastructure (PKI) - 将公用钥匙与各实体的身份联系起来的安排。这种约束是通过在证书颁发机构登记和颁发证书的过程建立起来的。
Public Switched Telephone Network (PSTN) - 传统的电话网包括固定电话和移动电话
Relying Party (RP) - 一般来说，一个应用程序依赖于用户与一个单独的认证提供者进行的认证。该应用程序依赖该认证提供者提供的某种标记或一组签名的断言，以相信用户是他们所说的那个人
Static application security testing (SAST) - 一套旨在分析应用程序源代码、字节码和二进制文件的技术，以发现表明安全漏洞的编码和设计条件。SAST解决方案在非运行状态下从 "内到外 "分析应用程序。
Software development lifecycle (SDLC) - 软件从最初的需求到部署和维护的一步步开发过程。
Security Architecture –应用程序设计的抽象，它确定并描述了安全控制的使用地点和方式，还确定并描述了用户和应用程序数据的位置和敏感性。
Security Configuration – 应用程序的运行时配置会影响安全控制的使用方式。
Security Control –执行安全检查（如访问控制检查）或在调用时产生安全效果（如生成审计记录）的功能或组件。
Server-side Request Forgery (SSRF) - 通过提供或修改服务器上运行的代码将读取或提交数据的URL，滥用服务器上的功能来读取或更新内部资源的攻击。
Single Sign-on Authentication (SSO) - 这种情况发生在用户登录一个应用程序，然后自动登录到其他应用程序，而无需重新认证。例如，当你登录谷歌时，在访问YouTube、谷歌文档和Gmail等其他谷歌服务时，你会自动登录。
SQL Injection (SQLi) – 一种用于攻击数据驱动的应用程序的代码注入技术，其中恶意SQL语句被插入到一个入口点。
SVG - 可缩放矢量图
Time-based OTP - 一种生成OTP的方法，其中当前时间作为生成密码的算法的一部分。
Threat Modeling - 一种由发展日益完善的安全架构组成的技术，以识别威胁因素、安全区域、安全控制以及重要的技术和业务资产
Transport Layer Security (TLS) – 在网络连接上提供通信安全的加密协议。
Trusted Platform Module (TPM) - HSM的一种类型，通常连接到一个更大的硬件组件，如主板，并作为该系统的 "信任根"。
Two-factor authentication (2FA) -这为账户登录增加了第二层认证。
Universal 2nd Factor (U2F) - FIDO专门为允许USB或NFC安全密钥作为第二认证因子而制定的标准之一。
URI/URL/URL fragments –统一资源标识符是用于标识名称或网络资源的一串字符。统一资源定位符通常用作资源的参考。
Verifier – 根据OWASP ASVS要求审查申请的人或小组。
What You See Is What You Get (WYSIWYG) -一种丰富的内容编辑器，它显示内容在渲染时的实际外观，而不是显示用于管理渲染的编码。
X.509 Certificate – X.509证书是一种数字证书，它使用被广泛接受的国际X.509公钥基础设施（PKI）标准来验证公钥是否属于证书中包含的用户、计算机或服务身份。
XML eXternal Entity (XXE) -一种可以通过声明的系统标识符访问本地或远程内容的XML实体类型。这可能加载到各种注入攻击

附录 B：参考文献

以下OWASP项目最有可能对本标准的用户/采用者有用:

OWASP 核心项目

OWASP Top 10 项目: https://owasp.org/www-project-top-ten/
OWASP Web安全测试指南: https://owasp.org/www-project-web-security-testing-guide/
OWASP 主动控制: https://owasp.org/www-project-proactive-controls/
OWASP 安全知识框架: https://owasp.org/www-project-security-knowledge-framework/
OWASP 软件保障成熟度模型(SAMM): https://owasp.org/www-project-samm/

OWASP Cheat Sheet 系列项目

此项目有许多备忘单，这些备忘单与 ASVS 中的不同主题相关。

有一个与ASVS的映射，可以在这里找到。 https://cheatsheetseries.owasp.org/cheatsheets/IndexASVS.html

移动安全相关项目

OWASP 移动安全项目: https://owasp.org/www-project-mobile-security/
OWASP 移动安全十大风险: https://owasp.org/www-project-mobile-top-10/
OWASP 移动安全测试指南和移动应用程序安全验证标准: https://owasp.org/www-project-mobile-security-testing-guide/

OWASP 物联网相关项目

OWASP 物联网项目: https://owasp.org/www-project-internet-of-things/

OWASP 无服务器项目

OWASP 无服务器项目: https://owasp.org/www-project-serverless-top-10/

其他

同样，以下网站最有可能对本标准的用户/采用者有用

安全列表 Github: https://github.com/danielmiessler/SecLists
MITRE常见弱点枚举: https://cwe.mitre.org/
PCI 安全标准理事会: https://www.pcisecuritystandards.org
PCI 数据安全标准（DSS） v3.2.1 要求和安全评估程序: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
PCI 软件安全框架 - 安全软件要求和评估程序: https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf
PCI 安全软件生命周期（安全 SLC）要求和评估程序: https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf

附录 C：物联网验证要求

本节最初在主分支中，但随着 OWASP IoT 团队完成的工作，维护有关主题的两个不同的线程没有意义。对于 4.0 版本，我们将此版本移动到附录中，并敦促所有需要此版本的人使用主 OWASP IoT 项目

控制目标

嵌入式/IoT 设备应当:

通过在受信任的环境中强制实施安全控制，在设备内具有与服务器中的相同级别的安全控制.
存储在设备上的敏感数据应使用硬件支持的存储方式（如安全元素）以安全的方式进行。
所有从设备传输的敏感数据都应保证传输层安全。.

安全验证要求

#	描述	L1	L2	L3	Since
C.1	验证应用程序层调试接口（如 USB、UART 和其他串行变体）是否被禁用或受复杂密码保护。	✓	✓	✓	4.0
C.2	验证加密密钥和证书是否对每个设备都是唯一的。	✓	✓	✓	4.0
C.3	验证嵌入式/IoT 操作系统（如果适用）是否启用了内存保护控制（如 ASLR 和 DEP）。	✓	✓	✓	4.0
C.4	验证芯片上调试接口（如 JTAG 或 SWD）是否已禁用，或者是否已正确启用和配置可用的保护机制。	✓	✓	✓	4.0
C.5	如果在设备SoC或CPU上可用，请验证是否实施并启用了可信执行。	✓	✓	✓	4.0
C.6	验证敏感数据、私钥和证书是否安全地存储在安全元素、TPM、TEE（可信执行环境）中，或使用强加密进行保护。	✓	✓	✓	4.0
C.7	验证固件应用是否使用传输层安全性保护传输中的数据。	✓	✓	✓	4.0
C.8	验证固件应用是否验证服务器连接的数字签名。	✓	✓	✓	4.0
C.9	验证无线通信是否相互验证。	✓	✓	✓	4.0
C.10	验证无线通信是否通过加密通道发送。	✓	✓	✓	4.0
C.11	验证对禁止的 C 函数的任何使用是否替换为适当的安全等效函数。	✓	✓	✓	4.0
C.12	确认每个固件都有一个软件材料清单，对第三方组件、版本和已发布的漏洞进行编目	✓	✓	✓	4.0
C.13	验证所有代码（包括第三方二进制文件、库、框架）是否经过硬编码凭据（后门）。	✓	✓	✓	4.0
C.14	通过调用 shell 命令解释器、脚本或安全控制阻止 OS 命令注入，验证应用程序和固件组件是否易受操作系统命令注入的影响。	✓	✓	✓	4.0
C.15	验证固件应用是否将数字签名固定到受信任的服务器。		✓	✓	4.0
C.16	验证是否存在防篡改和/或篡改检测功能。		✓	✓	4.0
C.17	验证芯片制造商提供的任何可用的知识产权保护技术是否已启用。		✓	✓	4.0
C.18	验证安全控制是否到位，以阻碍固件逆向工程（例如，删除冗长的调试符号）。		✓	✓	4.0
C.19	在加载之前验证设备验证引导映像签名。		✓	✓	4.0
C.20	验证固件更新过程是否容易受到检查时间与使用时间攻击的影响。		✓	✓	4.0
C.21	在安装之前，验证设备使用代码签名并验证固件升级文件。		✓	✓	4.0
C.22	验证设备是否无法降级到有效固件的旧版本（反回滚）。		✓	✓	4.0
C.23	验证嵌入式设备上加密安全的伪随机数生成器的使用（例如，使用芯片提供的随机数生成器）。		✓	✓	4.0
C.24	验证固件能否根据预定义计划执行自动固件更新。		✓	✓	4.0
C.25	在检测到篡改或收到无效消息时，验证设备是否擦除固件和敏感数据。			✓	4.0
C.26	验证是否仅使用支持禁用调试接口的微型控制器（例如 JTAG、SWD）。			✓	4.0
C.27	验证是否仅使用提供大量保护的微型控制器，防止除封盖和侧通道攻击。			✓	4.0
C.28	验证敏感轨迹是否未暴露在印刷电路板的外层。			✓	4.0
C.29	验证芯片间通信是否加密（例如主板到子板通信）。			✓	4.0
C.30	验证设备使用代码签名并在执行前验证代码。			✓	4.0
C.31	验证内存中维护的敏感信息在不再需要时是否被零覆盖。			✓	4.0
C.32	验证固件应用是否利用内核容器在应用之间进行隔离。			✓	4.0
C.33	验证安全编译器标志，如-fPIE、-fstack-protector-all、-Wl,-z,noexecstack、-Wl,-z,noexecheap是否为固件构建配置			✓	4.0
C.34	验证微型控制器是否配置了代码保护（如果适用）。			✓	4.0

参考文献

有关详细信息，请参阅:

程序安全开发规范--（应用程序安全验证标准）

应用程序安全验证标准 4.0.2

甘道夫 译

正面

关于标准

版权和许可

项目负责人

主要贡献者

其他贡献者和审阅者

前言

4.0中的新内容

使用 ASVS

应用程序安全验证级别

如何使用此标准

Level 1 – 最低限度

Level 2 - 大多数应用程序

Level 3 - 高价值、高保证或高安全性

在实践中应用 ASVS

如何参考 ASVS 要求

评估和认证

OWASP 对 ASVS 认证和信任标志的立场

认证组织指南

测试方法

自动安全测试工具的作用

渗透测试的作用

ASVS 的其他用途

作为详细的安全架构指南

作为现成的安全编码清单的替代品

作为自动化单元和集成测试指南

用于安全开发培训

作为敏捷应用程序安全性的驱动程序

作为指导安全软件采购的框架

V1：架构、设计和威胁建模要求

控制目标

V1.2 身份验证体系结构要求

V1.3 会话管理体系结构要求

V1.5 输入和输出架构要求

V1.6 加密体系结构要求

V1.7 错误、日志记录和审核体系结构要求

V1.8 数据保护和隐私体系结构要求

V1.9 通信体系结构要求

V1.10 恶意软件体系结构要求

V1.11 业务逻辑架构要求

V1.12 安全文件上传体系结构要求

V1.13 API 架构要求

参考文献

V2：身份验证验证要求

控制目标

NIST 800-63 - 现代的循证认证标准

选择适当的 NIST AAL 级别

V2.1 密码安全要求

V2.2 一般身份验证器要求

V2.3 身份验证器生命周期要求

V2.4 凭据存储要求

V2.6 查找秘密验证人要求

V2.7 带外验证器要求

V2.8 单因素或多因素一次验证器要求

V2.9 加密软件和设备验证程序要求

V2.10 服务身份验证要求

参考文献

V3: 会话管理验证要求

控制目标

安全验证要求

V3.3 会话注销和超时要求

V3.4 基于 Cookie 的会话管理

V3.5 基于令牌的会话管理

V3.6 重新认证联合身份验证或断言

V3.7 防御会话管理漏洞

半开攻击的描述

参考文献

V4：访问控制验证要求

控制目标

安全验证要求

V4.1 通用访问控制设计

V4.2 操作级访问控制

V4.3 其他访问控制注意事项

参考文献

V5：编码验证要求

控制目标

V5.1 输入验证要求

甘道夫译