跳转至

ASVS 应用安全验证标准

V1 编码与净化

V1.1 输入解码与输出编码（Input Decoding & Output Encoding）

编号 要求
V1.1.1 验证输入仅被解码或反转义为规范形式一次，且仅在预期接收该编码格式的数据时才进行解码，并且此操作在进一步处理输入之前完成，例如不在输入验证或净化之后执行。
V1.1.2 验证应用程序在被目标解释器使用之前的最后一步执行输出编码和转义，或由解释器本身执行。

V1.2 注入防护（Injection Prevention）

编号 要求
V1.2.1 验证 HTTP 响应、HTML 文档或 XML 文档的输出编码与所需上下文相关，例如对 HTML 元素、HTML 属性、HTML 注释、CSS 或 HTTP 头字段的相关字符进行编码，以避免改变消息或文档结构。
V1.2.2 验证动态构建 URL 时，不可信数据按其上下文进行编码（例如对查询或路径参数使用 URL 编码或 base64url 编码）。确保仅允许安全的 URL 协议（例如禁止 javascript: 或 data:）。
V1.2.3 验证动态构建 JavaScript 内容（包括 JSON）时使用输出编码或转义，以避免改变消息或文档结构（防止 JavaScript 和 JSON 注入）。
V1.2.4 验证数据查询（例如 SQL、HQL、NoSQL、Cypher）使用参数化查询、ORM、实体框架，或以其他方式防止 SQL 注入和其他数据库注入攻击。这也适用于编写存储过程。
V1.2.5 验证应用程序防止操作系统命令注入，且操作系统调用使用参数化 OS 查询或使用上下文命令行输出编码。
V1.2.6 验证应用程序防止 LDAP 注入漏洞，或已实施专门的安全控制来防止 LDAP 注入。
V1.2.7 验证应用程序通过使用查询参数化或预编译查询来防止 XPath 注入攻击。
V1.2.8 验证 LaTeX 处理器已安全配置（例如不使用 --shell-escape 标志），并使用命令白名单来防止 LaTeX 注入攻击。
V1.2.9 验证应用程序对正则表达式中的特殊字符进行转义（通常使用反斜杠），以防止它们被误解为元字符。
V1.2.10 验证应用程序防止 CSV 和公式注入。导出 CSV 内容时，应用程序必须遵循 RFC 4180 第 2.6 和 2.7 节定义的转义规则。此外，导出为 CSV 或其他电子表格格式（如 XLS、XLSX 或 ODF）时，如果特殊字符（包括 =、+、-、@、\t（制表符）和 \0（空字符））作为字段值的首字符出现，必须用单引号转义。

V1.3 净化（Sanitization）

编号 要求
V1.3.1 验证来自 WYSIWYG 编辑器或类似工具的所有不可信 HTML 输入，使用知名且安全的 HTML 净化库或框架功能进行净化。
V1.3.2 验证应用程序避免使用 eval() 或其他动态代码执行功能（如 Spring 表达式语言 SpEL）。如果没有替代方案，任何包含的用户输入在执行前必须经过净化。
V1.3.3 验证传递到潜在危险上下文的数据事先经过净化以强制安全措施，例如仅允许对该上下文安全的字符，并截断过长的输入。
V1.3.4 验证用户提供的可缩放矢量图形（SVG）脚本内容经过验证或净化，仅包含对应用程序安全的标签和属性（如绘图图形），例如不包含脚本和 foreignObject。
V1.3.5 验证应用程序净化或禁用用户提供的可脚本化或表达式模板语言内容，如 Markdown、CSS 或 XSL 样式表、BBCode 或类似内容。
V1.3.6 验证应用程序通过对不可信数据按协议、域名、路径和端口的白名单进行验证，并在调用其他服务之前净化潜在危险字符，来防止服务端请求伪造（SSRF）攻击。
V1.3.7 验证应用程序通过不允许基于不可信输入构建模板来防止模板注入攻击。如果没有替代方案，在模板创建期间动态包含的任何不可信输入必须经过净化或严格验证。
V1.3.8 验证应用程序在 JNDI 查询中使用不可信输入前进行适当净化，并且 JNDI 已安全配置以防止 JNDI 注入攻击。
V1.3.9 验证应用程序在将内容发送到 memcache 之前进行净化，以防止注入攻击。
V1.3.10 验证在处理可能以意外或恶意方式解析的格式字符串之前进行净化。
V1.3.11 验证应用程序在将用户输入传递给邮件系统之前进行净化，以防止 SMTP 或 IMAP 注入。
V1.3.12 验证正则表达式不含导致指数级回溯的元素，并确保不可信输入经过净化以缓解 ReDoS 或正则失控攻击。

V1.4 内存安全（Memory Safety）

编号 要求
V1.4.1 验证应用程序使用内存安全的字符串操作、更安全的内存复制和指针运算来检测或防止栈、缓冲区或堆溢出。
V1.4.2 验证使用符号、范围和输入验证技术来防止整数溢出。
V1.4.3 验证动态分配的内存和资源被释放，且对已释放内存的引用或指针被移除或设为 null，以防止悬空指针和释放后使用（Use-After-Free）漏洞。

V1.5 反序列化与解析安全（Deserialization & Parsing Safety）

编号 要求
V1.5.1 验证应用程序配置 XML 解析器使用限制性配置，且禁用解析外部实体等不安全功能，以防止 XML 外部实体（XXE）攻击。
V1.5.2 验证不可信数据的反序列化强制执行安全输入处理，例如使用对象类型白名单或限制客户端定义的对象类型，以防止反序列化攻击。明确定义为不安全的反序列化机制不得用于不可信输入。
V1.5.3 验证应用程序中用于同一数据类型的不同解析器（例如 JSON 解析器、XML 解析器、URL 解析器）以一致的方式执行解析，并使用相同的字符编码机制，以避免 JSON 互操作性漏洞或利用不同 URI 或文件解析行为的远程文件包含（RFI）或服务端请求伪造（SSRF）攻击。

V2 业务逻辑

V2.1 输入验证文档（Input Validation Documentation）

编号 要求
V2.1.1 验证应用程序文档定义了输入验证规则，说明如何按预期结构检查数据项的有效性。这可以是常见数据格式（如信用卡号、电子邮件地址、电话号码），也可以是内部数据格式。
V2.1.2 验证应用程序文档定义了如何验证组合数据项的逻辑和上下文一致性，例如检查区县和邮编是否匹配。
V2.1.3 验证业务逻辑限制和验证的期望已文档化，包括每用户和全应用范围的限制。

V2.2 输入验证实施（Input Validation Implementation）

编号 要求
V2.2.1 验证输入经过验证以强制执行该输入的业务或功能期望。应使用针对允许值、模式和范围的白名单进行正向验证，或根据预定义规则比较输入与预期结构和逻辑限制。对于 L1 级别，可重点关注用于特定业务或安全决策的输入。对于 L2 及以上，应适用于所有输入。
V2.2.2 验证应用程序设计为在可信服务层强制执行输入验证。虽然客户端验证可提高可用性且应予以鼓励，但不得将其作为安全控制依赖。
V2.2.3 验证应用程序确保相关数据项的组合根据预定义规则是合理的。

V2.3 业务逻辑流程（Business Logic Flow）

编号 要求
V2.3.1 验证应用程序仅按预期的顺序步骤为同一用户处理业务逻辑流程，且不跳过步骤。
V2.3.2 验证业务逻辑限制按应用程序文档实施，以避免业务逻辑缺陷被利用。
V2.3.3 验证在业务逻辑层使用事务，使业务逻辑操作要么完整成功，要么回滚到之前的正确状态。
V2.3.4 验证业务逻辑层使用锁定机制确保有限数量资源（如剧院座位或配送时段）不会因操纵应用程序逻辑而被重复预订。
V2.3.5 验证高价值业务逻辑流程需要多用户审批，以防止未经授权或意外操作。这可能包括但不限于大额资金转账、合同审批、访问机密信息或制造业安全覆盖。

V2.4 反自动化（Anti-automation）

编号 要求
V2.4.1 验证已实施反自动化控制，以防止对应用程序功能的过度调用，这些调用可能导致数据泄露、垃圾数据创建、配额耗尽、速率限制突破、拒绝服务或高成本资源的过度使用。
V2.4.2 验证业务逻辑流程要求符合实际的人类操作时间，防止过快的交易提交。

V3 Web 前端安全

V3.1 浏览器安全文档（Browser Security Documentation）

编号 要求
V3.1.1 验证应用程序文档说明了使用该应用程序的浏览器必须支持的预期安全功能（如 HTTPS、HTTP 严格传输安全 HSTS、内容安全策略 CSP 和其他相关 HTTP 安全机制）。还必须定义当这些功能不可用时应用程序的行为方式（如警告用户或阻止访问）。

V3.2 浏览器安全控制（Browser Security Controls）

编号 要求
V3.2.1 验证已实施安全控制以防止浏览器在错误上下文中渲染 HTTP 响应中的内容或功能（例如直接请求 API、用户上传的文件或其他资源时）。可能的控制措施包括：除非 HTTP 请求头字段（如 Sec-Fetch-*）指示为正确上下文，否则不提供内容；使用 Content-Security-Policy 头字段的 sandbox 指令；或在 Content-Disposition 头字段中使用 attachment 处置类型。
V3.2.2 验证旨在显示为文本而非渲染为 HTML 的内容，使用安全渲染函数（如 createTextNode 或 textContent）处理，以防止 HTML 或 JavaScript 等内容的非预期执行。
V3.2.3 验证应用程序在使用客户端 JavaScript 时，通过使用显式变量声明、执行严格类型检查、避免在 document 对象上存储全局变量以及实施命名空间隔离来避免 DOM 覆盖。
编号 要求
V3.3.1 验证 Cookie 设置了 Secure 属性，且如果 Cookie 名称未使用 __Host- 前缀，则必须使用 __Secure- 前缀。
V3.3.2 验证每个 Cookie 的 SameSite 属性值根据 Cookie 的用途进行设置，以限制用户界面伪装攻击和基于浏览器的请求伪造攻击（通常称为跨站请求伪造 CSRF）的暴露。
V3.3.3 验证 Cookie 的名称使用 __Host- 前缀，除非它们明确设计为与其他主机共享。
V3.3.4 验证如果 Cookie 值不打算被客户端脚本访问（如会话令牌），则 Cookie 必须设置 HttpOnly 属性，且相同值（如会话令牌）仅通过 Set-Cookie 头字段传输给客户端。
V3.3.5 验证当应用程序写入 Cookie 时，Cookie 名称和值的组合长度不超过 4096 字节。过大的 Cookie 不会被浏览器存储，因此不会随请求发送，从而阻止用户使用依赖该 Cookie 的应用功能。

V3.4 HTTP 安全头（HTTP Security Headers）

编号 要求
V3.4.1 验证所有响应中包含 Strict-Transport-Security 头字段以强制执行 HTTP 严格传输安全（HSTS）策略。必须定义至少 1 年的最大有效期，且对于 L2 及以上，策略必须适用于所有子域。
V3.4.2 验证跨域资源共享（CORS）的 Access-Control-Allow-Origin 头字段是应用程序设定的固定值，或如果使用 Origin HTTP 请求头字段值，则该值需要对照可信来源白名单进行验证。当需要使用 Access-Control-Allow-Origin: * 时，验证响应不包含任何敏感信息。
V3.4.3 验证 HTTP 响应包含 Content-Security-Policy 响应头字段，其指令确保浏览器仅加载和执行受信任的内容或资源，以限制恶意 JavaScript 的执行。至少全局策略必须包含 object-src 'none' 和 base-uri 'none' 指令，并定义白名单或使用 nonce 或哈希。对于 L3 应用，必须定义带有 nonce 或哈希的每响应策略。
V3.4.4 验证所有 HTTP 响应包含 X-Content-Type-Options: nosniff 头字段。这指示浏览器不对给定响应使用内容嗅探和 MIME 类型猜测，并要求响应的 Content-Type 头字段值与目标资源匹配。这还使浏览器能够使用跨域读取阻止（CORB）功能。
V3.4.5 验证应用程序设置了引用策略以防止技术敏感数据通过 Referer HTTP 请求头字段泄露给第三方服务。这可以通过 Referrer-Policy HTTP 响应头字段或 HTML 元素属性完成。敏感数据可能包括 URL 中的路径和查询数据，对于内部非公开应用还包括主机名。
V3.4.6 验证 Web 应用程序对每个 HTTP 响应使用 Content-Security-Policy 头字段的 frame-ancestors 指令，以确保默认不可被嵌入，且仅在必要时允许嵌入特定资源。注意 X-Frame-Options 头字段虽然被浏览器支持，但已过时且不可依赖。
V3.4.7 验证 Content-Security-Policy 头字段指定了报告违规的位置。
V3.4.8 验证所有发起文档渲染的 HTTP 响应（如 Content-Type 为 text/html 的响应）包含 Cross-Origin-Opener-Policy 头字段，使用 same-origin 指令或根据需要使用 same-origin-allow-popups 指令。这可防止利用共享 Window 对象访问的攻击，如标签页劫持和帧计数。

V3.5 浏览器源分离（Browser Origin Separation）

编号 要求
V3.5.1 验证如果应用不依赖 CORS 预检机制来阻止不允许的跨域请求访问敏感功能，则这些请求需被验证是否来源于应用自身。可通过使用和验证防伪造令牌（anti-forgery tokens），或要求非 CORS 安全列表请求头字段中的额外 HTTP 头字段来实现。此措施旨在防御基于浏览器的请求伪造攻击，通常称为跨站请求伪造（CSRF）。
V3.5.2 验证如果应用依赖 CORS 预检机制来防止不允许的跨域使用敏感功能，则无法使用不触发 CORS 预检请求的请求来调用该功能。这可能需要检查 Origin 和 Content-Type 请求头字段的值，或使用非 CORS 安全列表头字段中的额外头字段。
V3.5.3 验证敏感功能的 HTTP 请求使用适当的 HTTP 方法（如 POST、PUT、PATCH 或 DELETE），而非 HTTP 规范定义的"安全"方法（如 HEAD、OPTIONS 或 GET）。或者，可以使用 Sec-Fetch-* 请求头字段的严格验证来确保请求不是来自不适当的跨域调用、导航请求或资源加载（如图片源）。
V3.5.4 验证独立的应用托管在不同的主机名上，以利用同源策略提供的限制，包括一个源加载的文档或脚本如何与另一个源的资源交互，以及基于主机名的 Cookie 限制。
V3.5.5 验证通过 postMessage 接口接收的消息，如果消息的来源不可信或消息语法无效，则会被丢弃。
V3.5.6 验证应用中任何位置均未启用 JSONP 功能，以避免跨站脚本包含（XSSI）攻击。
V3.5.7 验证需要授权的数据未包含在脚本资源响应中（如 JavaScript 文件），以防止跨站脚本包含（XSSI）攻击。
V3.5.8 验证已认证的资源（如图片、视频、脚本和其他文档）仅在用户预期时才能被加载或嵌入。可通过严格验证 Sec-Fetch-* HTTP 请求头字段以确保请求不是来自不适当的跨域调用，或设置限制性的 Cross-Origin-Resource-Policy HTTP 响应头字段指示浏览器阻止返回的内容来实现。

V3.6 外部资源完整性（External Resource Integrity）

编号 要求
V3.6.1 验证客户端资产（如 JavaScript 库、CSS 或 Web 字体）仅在资源为静态且有版本控制并使用子资源完整性（SRI）验证资产完整性时，才托管在外部（如 CDN 上）。如果无法做到这一点，则应为每个资源记录安全决策以证明其合理性。

V3.7 其他浏览器安全考量（Other Browser Security Considerations）

编号 要求
V3.7.1 验证应用仅使用仍受支持且被认为安全的客户端技术。不符合此要求的技术示例包括 NSAPI 插件、Flash、Shockwave、ActiveX、Silverlight、NACL 或客户端 Java Applet。
V3.7.2 验证应用仅在目标出现在允许列表中时，才会自动将用户重定向到非应用控制的不同主机名或域名。
V3.7.3 验证当用户被重定向到应用控制之外的 URL 时，应用会显示通知并提供取消导航的选项。
V3.7.4 验证应用的顶级域名（如 site.tld）已添加到 HTTP 严格传输安全（HSTS）的公共预加载列表中。这确保了应用对 TLS 的使用直接内置于主流浏览器中，而不仅仅依赖 Strict-Transport-Security 响应头字段。
V3.7.5 验证如果用于访问应用的浏览器不支持预期的安全特性，应用会按照文档记录的方式行事（如警告用户或阻止访问）。

V4 API 和 Web 服务

V4.1 通用 Web 服务安全（Generic Web Service Security）

编号 要求
V4.1.1 验证每个包含消息体的 HTTP 响应都包含与响应实际内容匹配的 Content-Type 头字段，包括根据 IANA 媒体类型指定安全字符编码的 charset 参数（如 UTF-8、ISO-8859-1），例如 text/*、*/+xml 和 */xml。
V4.1.2 验证仅面向用户的端点（用于手动 Web 浏览器访问）自动从 HTTP 重定向到 HTTPS，而其他服务或端点不实施透明重定向。这是为了避免客户端错误发送未加密的 HTTP 请求时，由于请求被自动重定向到 HTTPS 而导致敏感数据泄露未被发现。
V4.1.3 验证应用使用的且由中间层（如负载均衡器、Web 代理或 BFF 服务）设置的任何 HTTP 头字段不能被终端用户覆盖。示例头可能包括 X-Real-IP、X-Forwarded-* 或 X-User-ID。
V4.1.4 验证仅允许应用或其 API 显式支持的 HTTP 方法（包括预检请求期间的 OPTIONS），未使用的方法被阻止。
V4.1.5 验证对于高度敏感或跨越多个系统的请求或事务，在传输保护之上使用按消息数字签名以提供额外保证。

V4.2 HTTP 消息结构验证（HTTP Message Structure Validation）

编号 要求
V4.2.1 验证所有应用组件（包括负载均衡器、防火墙和应用服务器）使用适合 HTTP 版本的机制确定传入 HTTP 消息的边界，以防止 HTTP 请求走私。在 HTTP/1.x 中，如果存在 Transfer-Encoding 头字段，则必须根据 RFC 2616 忽略 Content-Length 头。使用 HTTP/2 或 HTTP/3 时，如果存在 Content-Length 头字段，接收方必须确保其与 DATA 帧的长度一致。
V4.2.2 验证生成 HTTP 消息时，Content-Length 头字段不与 HTTP 协议帧确定的内容长度冲突，以防止请求走私攻击。
V4.2.3 验证应用不发送也不接受包含连接特定头字段（如 Transfer-Encoding）的 HTTP/2 或 HTTP/3 消息，以防止响应拆分和头注入攻击。
V4.2.4 验证应用仅接受头字段和值中不包含任何 CR（\r）、LF（\n）或 CRLF（\r\n）序列的 HTTP/2 和 HTTP/3 请求，以防止头注入攻击。
V4.2.5 验证如果应用（后端或前端）构建并发送请求，它使用验证、净化或其他机制避免创建过长的 URI（如 API 调用）或 HTTP 请求头字段（如 Authorization 或 Cookie），使其不被接收组件拒绝。这可能导致拒绝服务，例如发送过长请求（如过长的 Cookie 头字段）导致服务器始终响应错误状态。

V4.3 GraphQL

编号 要求
V4.3.1 验证使用查询允许列表、深度限制、数量限制或查询成本分析来防止由于昂贵的嵌套查询导致的 GraphQL 或数据层表达式拒绝服务（DoS）。
V4.3.2 验证生产环境中禁用 GraphQL 内省查询，除非 GraphQL API 旨在供其他方使用。

V4.4 WebSocket

编号 要求
V4.4.1 验证所有 WebSocket 连接均使用基于 TLS 的 WebSocket（WSS）。
V4.4.2 验证在初始 HTTP WebSocket 握手期间，Origin 头字段根据应用允许的源列表进行检查。
V4.4.3 验证如果不能使用应用的标准会话管理，则使用专用令牌，且这些令牌符合相关的会话管理安全要求。
V4.4.4 验证将现有 HTTPS 会话转换为 WebSocket 通道时，专用 WebSocket 会话管理令牌最初通过先前已认证的 HTTPS 会话获取或验证。

V5 文件处理

V5.1 文件处理文档（File Handling Documentation）

编号 要求
V5.1.1 验证文档定义了每个上传功能允许的文件类型、预期文件扩展名和最大大小（包括解压后大小）。此外，确保文档规定了如何使文件对终端用户安全下载和处理，例如当检测到恶意文件时应用的行为。

V5.2 文件上传和内容（File Upload and Content）

编号 要求
V5.2.1 验证应用仅接受能在不导致性能下降或拒绝服务攻击的情况下处理的文件大小。
V5.2.2 验证当应用接受文件（单独或在 zip 等存档文件中）时，检查文件扩展名是否匹配预期的文件扩展名，并验证内容对应于扩展名表示的类型。这包括但不限于检查初始"魔术字节"、执行图像重写以及使用专门的库进行文件内容验证。对于 L1，可以仅关注用于做出特定业务或安全决策的文件。对于 L2 及以上，必须适用于所有接受的文件。
V5.2.3 验证应用在解压前检查压缩文件（如 zip、gz、docx、odt）的最大允许解压大小和最大文件数量。
V5.2.4 验证实施了文件大小配额和每用户最大文件数限制，以确保单个用户不能用过多或过大的文件填满存储空间。
V5.2.5 验证应用不允许上传包含符号链接的压缩文件，除非有特定需求（此时需要强制执行可被链接到的文件的允许列表）。
V5.2.6 验证应用拒绝像素尺寸大于最大允许值的上传图像，以防止像素洪水攻击。

V5.3 文件存储（File Storage）

编号 要求
V5.3.1 验证由不受信任的输入上传或生成并存储在公共文件夹中的文件，在通过 HTTP 请求直接访问时不会作为服务器端程序代码执行。
V5.3.2 验证当应用为文件操作创建文件路径时，使用内部生成或受信任的数据替代用户提交的文件名；如果必须使用用户提交的文件名或文件元数据，则必须应用严格的验证和净化。这是为了防止路径遍历、本地或远程文件包含（LFI、RFI）和服务器端请求伪造（SSRF）攻击。
V5.3.3 验证服务器端文件处理（如文件解压）忽略用户提供的路径信息，以防止 zip slip 等漏洞。

V5.4 文件下载（File Download）

编号 要求
V5.4.1 验证应用验证或忽略用户提交的文件名（包括 JSON、JSONP 或 URL 参数中的），并在响应的 Content-Disposition 头字段中指定文件名。
V5.4.2 验证提供的文件名（如在 HTTP 响应头字段或电子邮件附件中）经过编码或净化（如遵循 RFC 6266），以保留文档结构并防止注入攻击。
V5.4.3 验证从不受信任来源获取的文件经过防病毒扫描器扫描，以防止提供已知的恶意内容。

V6 认证

V6.1 认证文档（Authentication Documentation）

编号 要求
V6.1.1 验证应用文档定义了如何使用速率限制、反自动化和自适应响应等控制措施来防御凭证填充和密码暴力破解等攻击。文档必须说明这些控制如何配置以及如何防止恶意账户锁定。
V6.1.2 验证记录了上下文特定词汇列表，以防止在密码中使用。该列表可能包括组织名称、产品名称、系统标识符、项目代号、部门或角色名称及其变体。
V6.1.3 验证如果应用包含多种认证路径，这些路径连同必须在所有路径中一致执行的安全控制和认证强度一起记录。

V6.2 密码安全（Password Security）

编号 要求
V6.2.1 验证用户设置的密码至少为 8 个字符，但强烈建议最少 15 个字符。
V6.2.2 验证用户可以更改密码。
V6.2.3 验证密码更改功能要求用户输入当前密码和新密码。
V6.2.4 验证账户注册或密码更改期间提交的密码会与至少前 3000 个匹配应用密码策略（如最低长度）的常用密码集进行比对。
V6.2.5 验证可以使用任何组合的密码，不限制允许的字符类型。不得要求大写或小写字母、数字或特殊字符的最低数量。
V6.2.6 验证密码输入字段使用 type=password 来掩码输入。应用可以允许用户临时查看整个被掩码的密码，或密码的最后输入字符。
V6.2.7 验证允许"粘贴"功能、浏览器密码助手和外部密码管理器。
V6.2.8 验证应用按用户输入的原样验证密码，不进行任何修改（如截断或大小写转换）。
V6.2.9 验证允许至少 64 个字符长度的密码。
V6.2.10 验证用户的密码在被发现泄露或用户主动轮换之前保持有效。应用不得要求定期凭证轮换。
V6.2.11 验证使用记录的上下文特定词汇列表来防止创建容易猜测的密码。
V6.2.12 验证账户注册或密码更改期间提交的密码会与泄露密码集进行比对。

V6.3 通用认证安全（General Authentication Security）

编号 要求
V6.3.1 验证根据应用安全文档实施了防止凭证填充和密码暴力破解等攻击的控制措施。
V6.3.2 验证默认用户账户（如 "root"、"admin" 或 "sa"）不存在于应用中或已被禁用。
V6.3.3 验证必须使用多因素认证机制或单因素认证机制的组合才能访问应用。对于 L3，其中一个因素必须是基于硬件的认证机制，能够提供抗钓鱼攻击的冒充和妥协抵抗能力，同时通过要求用户发起的操作（如按下 FIDO 硬件密钥上的按钮或手机上的操作）来验证认证意图。放宽此要求中的任何考虑因素需要完整记录的理由和全面的缓解控制措施。
V6.3.4 验证如果应用包含多种认证路径，不存在未记录的路径，且安全控制和认证强度在所有路径中一致执行。
V6.3.5 验证用户在可疑认证尝试（成功或失败）时收到通知。这可能包括来自异常位置或客户端的认证尝试、部分成功的认证（仅一个因素）、长时间不活动后的认证尝试或多次失败尝试后的成功认证。
V6.3.6 验证电子邮件不作为单因素或多因素认证机制使用。
V6.3.7 验证用户在认证详细信息更新后收到通知，如凭证重置或用户名或电子邮件地址的修改。
V6.3.8 验证无法从失败的认证质询中推断出有效用户，例如基于错误消息、HTTP 响应代码或不同的响应时间。注册和忘记密码功能也必须具备此保护。

V6.4 认证因素生命周期和恢复（Authentication Factor Lifecycle and Recovery）

编号 要求
V6.4.1 验证系统生成的初始密码或激活码是安全随机生成的，遵循现有密码策略，并在短时间内或首次使用后过期。这些初始密钥不得允许成为长期密码。
V6.4.2 验证不存在密码提示或基于知识的认证（即所谓的"安全问题"）。
V6.4.3 验证实施了忘记密码的安全重置流程，且不会绕过任何已启用的多因素认证机制。
V6.4.4 验证如果多因素认证因素丢失，身份证明会在与注册时相同的级别进行。
V6.4.5 验证在旧认证机制到期之前有足够时间发送更新说明，必要时配置自动提醒。
V6.4.6 验证管理员可以为用户启动密码重置流程，但不能更改或选择用户的密码。这防止了管理员知道用户密码的情况。

V6.5 通用多因素认证要求（General Multi-factor Authentication Requirements）

编号 要求
V6.5.1 验证查找密钥（lookup secrets）、带外认证请求或代码以及基于时间的一次性密码（TOTP）仅能成功使用一次。
V6.5.2 验证当存储在应用后端时，熵值低于 112 位（19 个随机字母数字字符或 34 个随机数字）的查找密钥使用经过批准的密码存储哈希算法（包含 32 位随机盐）进行哈希处理。如果密钥具有 112 位或更多的熵值，可以使用标准哈希函数。
V6.5.3 验证查找密钥、带外认证代码和基于时间的一次性密码种子使用加密安全伪随机数生成器（CSPRNG）生成，以避免可预测的值。
V6.5.4 验证查找密钥和带外认证代码具有至少 20 位的熵值（通常 4 个随机字母数字字符或 6 个随机数字即可）。
V6.5.5 验证带外认证请求、代码或令牌以及基于时间的一次性密码（TOTP）具有定义的生存期。带外请求的最大生存期为 10 分钟，TOTP 的最大生存期为 30 秒。
V6.5.6 验证任何认证因素（包括物理设备）在被盗或其他丢失情况下可以被撤销。
V6.5.7 验证生物识别认证机制仅作为次要因素与"你拥有的东西"或"你知道的东西"结合使用。
V6.5.8 验证基于时间的一次性密码（TOTP）基于可信服务的时间源进行检查，而非不可信或客户端提供的时间。

V6.6 带外认证机制（Out-of-Band Authentication Mechanisms）

编号 要求
V6.6.1 验证使用公共交换电话网络（PSTN）通过电话或短信传送一次性密码（OTP）的认证机制仅在电话号码先前已验证、同时提供更强的替代方法（如基于时间的一次性密码）且服务向用户提供安全风险信息时才提供。对于 L3 应用，不得提供电话和短信选项。
V6.6.2 验证带外认证请求、代码或令牌绑定到生成它们的原始认证请求，不能用于之前或之后的认证请求。
V6.6.3 验证基于代码的带外认证机制通过速率限制防止暴力破解攻击。同时考虑使用至少 64 位熵值的代码。
V6.6.4 验证当推送通知用于多因素认证时，使用速率限制来防止推送轰炸攻击。数字匹配也可以缓解此风险。

V6.7 加密认证机制（Cryptographic Authentication Mechanism）

编号 要求
V6.7.1 验证用于验证加密认证断言的证书以防止修改的方式存储。
V6.7.2 验证挑战随机数（nonce）至少为 64 位长度，在统计上唯一或在加密设备的生命周期内唯一。

V6.8 基于身份提供者的认证（Authentication with an Identity Provider）

编号 要求
V6.8.1 验证如果应用支持多个身份提供者（IdP），用户的身份不能通过另一个受支持的身份提供者被冒充（例如使用相同的用户标识符）。标准缓解措施是应用使用 IdP ID（作为命名空间）和用户在 IdP 中的 ID 的组合来注册和识别用户。
V6.8.2 验证认证断言上的数字签名（例如 JWT 或 SAML 断言）的存在和完整性始终被验证，拒绝任何未签名或签名无效的断言。
V6.8.3 验证 SAML 断言在有效期内仅被处理和使用一次，以防止重放攻击。
V6.8.4 验证如果应用使用单独的身份提供者（IdP）并期望特定功能具有特定的认证强度、方法或最近性，应用使用 IdP 返回的信息进行验证。例如，如果使用 OIDC，可以通过验证 ID Token 声明（如 acr、amr 和 auth_time，如果存在）来实现。如果 IdP 不提供此信息，应用必须有记录的回退方法，假定使用了最低强度的认证机制（例如使用用户名和密码的单因素认证）。

V7 会话管理

V7.1 会话管理文档（Session Management Documentation）

编号 要求
V7.1.1 验证用户会话不活动超时和绝对最大会话生命周期已记录，与其他控制措施结合是适当的，且文档包含对偏离 NIST SP 800-63B 重新认证要求的任何偏差的理由。
V7.1.2 验证文档定义了一个账户允许的并发（并行）会话数量，以及达到最大活跃会话数时的预期行为和采取的措施。
V7.1.3 验证在联合身份管理生态系统（如 SSO 系统）中创建和管理用户会话的所有系统都已记录，包括协调会话生命周期、终止以及任何需要重新认证的条件的控制措施。

V7.2 基本会话管理安全（Fundamental Session Management Security）

编号 要求
V7.2.1 验证应用使用受信任的后端服务执行所有会话令牌验证。
V7.2.2 验证应用使用动态生成的自包含或引用令牌进行会话管理，即不使用静态 API 密钥和密钥。
V7.2.3 验证如果使用引用令牌表示用户会话，它们是唯一的，使用加密安全伪随机数生成器（CSPRNG）生成，并具有至少 128 位的熵值。
V7.2.4 验证应用在用户认证（包括重新认证）时生成新的会话令牌并终止当前会话令牌。

V7.3 会话超时（Session Timeout）

编号 要求
V7.3.1 验证存在不活动超时，根据风险分析和记录的安全决策强制执行重新认证。
V7.3.2 验证存在绝对最大会话生命周期，根据风险分析和记录的安全决策强制执行重新认证。

V7.4 会话终止（Session Termination）

编号 要求
V7.4.1 验证当会话终止被触发（如登出或过期）时，应用不允许进一步使用该会话。对于引用令牌或有状态会话，这意味着在应用后端使会话数据无效。使用自包含令牌的应用需要维护已终止令牌列表、禁止在每用户日期时间之前生成的令牌或轮换每用户签名密钥等解决方案。
V7.4.2 验证当用户账户被禁用或删除（如员工离职）时，应用终止所有活跃会话。
V7.4.3 验证在成功更改或移除任何认证因素（包括通过重置或恢复更改密码以及 MFA 设置更新，如果存在）后，应用提供终止所有其他活跃会话的选项。
V7.4.4 验证所有需要认证的页面都有简单且可见的登出功能入口。
V7.4.5 验证应用管理员能够终止单个用户或所有用户的活跃会话。

V7.5 防御会话滥用（Defenses Against Session Abuse）

编号 要求
V7.5.1 验证在允许修改可能影响认证的敏感账户属性（如电子邮件地址、电话号码、MFA 配置或用于账户恢复的其他信息）之前，应用要求完全重新认证。
V7.5.2 验证用户能够查看并（再次使用至少一个因素认证后）终止任何或所有当前活跃会话。
V7.5.3 验证应用在执行高度敏感的交易或操作之前，要求使用至少一个因素的进一步认证或二次验证。

V7.6 联合重新认证（Federated Re-authentication）

编号 要求
V7.6.1 验证依赖方（RP）和身份提供者（IdP）之间的会话生命周期和终止行为如文档记录，在必要时（如达到 IdP 认证事件之间的最大时间时）要求重新认证。
V7.6.2 验证会话的创建需要用户的同意或明确操作，防止在没有用户交互的情况下创建新的应用会话。

V8 授权

V8.1 授权文档（Authorization Documentation）

编号 要求
V8.1.1 验证授权文档定义了基于消费者权限和资源属性限制功能级别和数据特定访问的规则。
V8.1.2 验证授权文档定义了基于消费者权限和资源属性的字段级别访问限制（读和写）规则。注意这些规则可能取决于相关数据对象的其他属性值，如状态（state 或 status）。
V8.1.3 验证应用文档定义了用于做出安全决策的环境和上下文属性（包括但不限于时间、用户位置、IP 地址或设备），包括与认证和授权相关的决策。
V8.1.4 验证认证和授权文档定义了环境和上下文因素在决策中的使用方式，除功能级别、数据特定和字段级别授权外。这应包括评估的属性、风险阈值和采取的操作（如允许、质询、拒绝、升级认证）。

V8.2 通用授权设计（General Authorization Design）

编号 要求
V8.2.1 验证应用确保功能级别访问仅限于具有显式权限的消费者。
V8.2.2 验证应用确保数据特定访问仅限于具有对特定数据项显式权限的消费者，以缓解不安全直接对象引用（IDOR）和破坏的对象级别授权（BOLA）。
V8.2.3 验证应用确保字段级别访问仅限于具有对特定字段显式权限的消费者，以缓解破坏的对象属性级别授权（BOPLA）。
V8.2.4 验证基于消费者环境和上下文属性（如时间、位置、IP 地址或设备）的自适应安全控制已按应用文档定义实施用于认证和授权决策。这些控制必须在消费者尝试启动新会话时以及在现有会话期间应用。

V8.3 操作级别授权（Operation Level Authorization）

编号 要求
V8.3.1 验证应用在受信任的服务层执行授权规则，不依赖不受信任的消费者可以操纵的控制（如客户端 JavaScript）。
V8.3.2 验证对授权决策所依据的值的更改立即生效。当更改无法立即应用时（如依赖自包含令牌中的数据），必须有缓解控制措施，以在消费者不再被授权执行操作时发出警报并恢复更改。注意这种替代方案不会缓解信息泄露。
V8.3.3 验证对对象的访问基于发起主体（如消费者）的权限，而非代表其行事的任何中介或服务的权限。例如，如果消费者使用自包含令牌调用 Web 服务进行认证，该服务随后从另一个服务请求数据，第二个服务将使用消费者的令牌而非第一个服务的机器对机器令牌来做出权限决策。

V8.4 其他授权考量（Other Authorization Considerations）

编号 要求
V8.4.1 验证多租户应用使用跨租户控制，确保消费者操作永远不会影响其无权交互的租户。
V8.4.2 验证对管理接口的访问包含多层安全，包括持续的消费者身份验证、设备安全状态评估和上下文风险分析，确保网络位置或受信任端点不是授权的唯一因素，尽管它们可能降低未授权访问的可能性。

V9 自包含令牌

V9.1 令牌来源和完整性（Token Source and Integrity）

编号 要求
V9.1.1 验证自包含令牌在接受令牌内容之前使用其数字签名或 MAC 进行验证以防止篡改。
V9.1.2 验证在给定上下文中，仅允许使用允许列表上的算法来创建和验证自包含令牌。允许列表必须包含允许的算法，理想情况下仅包含对称或非对称算法，且不得包含"None"算法。如果必须同时支持对称和非对称算法，则需要额外控制以防止密钥混淆。
V9.1.3 验证用于验证自包含令牌的密钥材料来自令牌发行者的受信任预配置来源，防止攻击者指定不受信任的来源和密钥。对于 JWT 和其他 JWS 结构，头部如 jku、x5u 和 jwk 必须根据受信任来源的允许列表进行验证。

V9.2 令牌内容（Token Content）

编号 要求
V9.2.1 验证如果令牌数据中存在有效时间跨度，仅在验证时间在此有效时间跨度内时才接受令牌及其内容。例如，对于 JWT，必须验证 nbf 和 exp 声明。
V9.2.2 验证接收令牌的服务在接受令牌内容之前验证令牌是否为正确类型且用于预期目的。例如，仅访问令牌可用于授权决策，仅 ID 令牌可用于证明用户认证。
V9.2.3 验证服务仅接受旨在用于该服务（受众）的令牌。对于 JWT，可通过根据服务中定义的允许列表验证 aud 声明来实现。
V9.2.4 验证如果令牌发行者使用相同的私钥向不同受众发行令牌，则发行的令牌包含唯一标识预期受众的受众限制。这将防止令牌被用于非预期的受众。如果受众标识符是动态配置的，令牌发行者必须验证这些受众以确保不会导致受众冒充。

V10 OAuth 和 OIDC

V10.1 通用 OAuth 和 OIDC 安全（Generic OAuth and OIDC Security）

编号 要求
V10.1.1 验证令牌仅发送给严格需要它们的组件。例如，在为基于浏览器的 JavaScript 应用使用后端为前端（BFF）模式时，访问令牌和刷新令牌只能由后端访问。
V10.1.2 验证客户端仅在这些值来自由同一用户代理会话和事务发起的授权流程时，才接受来自授权服务器的值（如授权码或 ID Token）。这要求客户端生成的密钥（如 PKCE 的 code_verifier、state 或 OIDC 的 nonce）不可猜测、特定于事务，并安全绑定到客户端和发起事务的用户代理会话。

V10.2 OAuth 客户端（OAuth Client）

编号 要求
V10.2.1 验证如果使用授权码流程，OAuth 客户端通过使用代码交换证明密钥（PKCE）功能或检查授权请求中发送的 state 参数来防御触发令牌请求的基于浏览器的请求伪造攻击（CSRF）。
V10.2.2 验证如果 OAuth 客户端可以与多个授权服务器交互，则具有防御混淆攻击的机制。例如，可以要求授权服务器返回 iss 参数值，并在授权响应和令牌响应中进行验证。
V10.2.3 验证 OAuth 客户端仅在向授权服务器的请求中请求所需的范围（或其他授权参数）。

V10.3 OAuth 资源服务器（OAuth Resource Server）

编号 要求
V10.3.1 验证资源服务器仅接受旨在用于该服务（受众）的访问令牌。受众可以包含在结构化访问令牌中（如 JWT 中的 aud 声明），或可以使用令牌内省端点进行检查。
V10.3.2 验证资源服务器基于访问令牌中定义委托授权的声明执行授权决策。如果存在 sub、scope 和 authorization_details 等声明，它们必须是决策的一部分。
V10.3.3 验证如果访问控制决策需要从访问令牌（JWT 或相关令牌内省响应）中识别唯一用户，资源服务器使用不能重新分配给其他用户的声明来识别用户。通常这意味着使用 iss 和 sub 声明的组合。
V10.3.4 验证如果资源服务器要求特定的认证强度、方法或最近性，它会验证提供的访问令牌满足这些约束。例如，如果存在，分别使用 OIDC 的 acr、amr 和 auth_time 声明。
V10.3.5 验证资源服务器通过要求发送方约束的访问令牌（OAuth 2 的 Mutual TLS 或 OAuth 2 的 DPoP 持有证明）来防止被盗访问令牌的使用或未授权方的访问令牌重放。

V10.4 OAuth 授权服务器（OAuth Authorization Server）

编号 要求
V10.4.1 验证授权服务器使用精确字符串比较，基于客户端特定的预注册 URI 允许列表验证重定向 URI。
V10.4.2 验证如果授权服务器在授权响应中返回授权码，该授权码只能用于一次令牌请求。对于第二次使用已用于发行访问令牌的授权码的有效请求，授权服务器必须拒绝令牌请求并撤销与该授权码相关的任何已发行令牌。
V10.4.3 验证授权码是短期的。L1 和 L2 应用的最大生命周期可达 10 分钟，L3 应用可达 1 分钟。
V10.4.4 验证对于给定客户端，授权服务器仅允许使用该客户端需要使用的授权类型。注意 token（隐式流程）和 password（资源所有者密码凭证流程）授权类型不得再使用。
V10.4.5 验证授权服务器缓解公共客户端的刷新令牌重放攻击，优先使用发送方约束的刷新令牌（即 DPoP 或使用 mTLS 的证书绑定访问令牌）。对于 L1 和 L2 应用，可以使用刷新令牌轮换。如果使用刷新令牌轮换，授权服务器必须在使用后使刷新令牌无效，且如果提供了已使用和无效的刷新令牌，则撤销该授权的所有刷新令牌。
V10.4.6 验证如果使用授权码授权，授权服务器通过要求代码交换证明密钥（PKCE）来缓解授权码拦截攻击。对于授权请求，授权服务器必须要求有效的 code_challenge 值，且不接受 code_challenge_method 值为 plain。对于令牌请求，必须要求验证 code_verifier 参数。
V10.4.7 验证如果授权服务器支持未认证的动态客户端注册，它会缓解恶意客户端应用的风险。必须验证客户端元数据（如任何注册的 URI）、确保用户同意，并在处理不受信任客户端应用的授权请求之前警告用户。
V10.4.8 验证刷新令牌具有绝对过期时间，包括在应用滑动刷新令牌过期时。
V10.4.9 验证刷新令牌和引用访问令牌可以由授权用户通过授权服务器用户界面撤销，以缓解恶意客户端或被盗令牌的风险。
V10.4.10 验证机密客户端在向授权服务器的后端通道请求（如令牌请求、推送授权请求 PAR 和令牌撤销请求）中进行认证。
V10.4.11 验证授权服务器配置仅向 OAuth 客户端分配所需的范围。
V10.4.12 验证对于给定客户端，授权服务器仅允许该客户端需要使用的 response_mode 值。例如，通过让授权服务器根据预期值验证此值，或使用推送授权请求（PAR）或 JWT 安全授权请求（JAR）。
V10.4.13 验证授权类型 code 始终与推送授权请求（PAR）一起使用。
V10.4.14 验证授权服务器仅发行发送方约束（持有证明）的访问令牌，使用 mTLS 的证书绑定访问令牌或 DPoP 绑定的访问令牌（持有证明演示）。
V10.4.15 验证对于服务器端客户端（不在终端用户设备上执行），授权服务器确保 authorization_details 参数值来自客户端后端，且用户未篡改。例如，通过要求使用推送授权请求（PAR）或 JWT 安全授权请求（JAR）。
V10.4.16 验证客户端是机密的，且授权服务器要求使用基于公钥加密且抗重放攻击的强客户端认证方法，如 Mutual TLS（tls_client_auth、self_signed_tls_client_auth）或私钥 JWT（private_key_jwt）。

V10.5 OIDC 客户端（OIDC Client）

编号 要求
V10.5.1 验证客户端（作为依赖方）缓解 ID Token 重放攻击。例如，通过确保 ID Token 中的 nonce 声明与发送到 OpenID 提供者的认证请求中的 nonce 值匹配。
V10.5.2 验证客户端使用 ID Token 声明唯一标识用户，通常是不能重新分配给其他用户的 sub 声明（在身份提供者范围内）。
V10.5.3 验证客户端拒绝恶意授权服务器通过授权服务器元数据冒充另一个授权服务器的尝试。如果授权服务器元数据中的发行者 URL 与客户端预配置的预期发行者 URL 不完全匹配，客户端必须拒绝授权服务器元数据。
V10.5.4 验证客户端通过检查令牌中的 aud 声明是否等于客户端的 client_id 值，来验证 ID Token 旨在用于该客户端（受众）。
V10.5.5 验证当使用 OIDC 后端通道登出时，依赖方缓解通过强制登出和登出流程中跨 JWT 混淆导致的拒绝服务。客户端必须验证登出令牌正确类型化，值为 logout+jwt，包含具有正确成员名称的 event 声明，且不包含 nonce 声明。注意还建议设置较短的过期时间（如 2 分钟）。

V10.6 OpenID 提供者（OpenID Provider）

编号 要求
V10.6.1 验证 OpenID 提供者仅允许 code、ciba、id_token 或 id_token code 作为响应模式的值。注意 code 优于 id_token code（OIDC 混合流程），且不得使用 token（任何隐式流程）。
V10.6.2 验证 OpenID 提供者缓解通过强制登出导致的拒绝服务。通过获取终端用户的明确确认，或如果存在，验证登出请求（由依赖方发起）中的参数，如 id_token_hint。
编号 要求
V10.7.1 验证授权服务器确保用户同意每个授权请求。如果无法保证客户端身份，授权服务器必须始终明确提示用户同意。
V10.7.2 验证当授权服务器提示用户同意时，呈现关于同意内容的充分和清晰信息。在适用时，这应包括请求的授权性质（通常基于范围、资源服务器、富授权请求 RAR 授权详情）、授权应用的身份和这些授权的生命周期。
V10.7.3 验证用户可以通过授权服务器审查、修改和撤销已授予的同意。

V11 密码学

V11.1 密码学清单和文档（Cryptographic Inventory and Documentation）

编号 要求
V11.1.1 验证存在已记录的密钥管理策略和遵循 NIST SP 800-57 等密钥管理标准的加密密钥生命周期。这应包括确保密钥不被过度共享（例如，共享密钥不超过两个实体，私钥不超过一个实体）。
V11.1.2 验证执行、维护并定期更新密码学清单，包括应用使用的所有加密密钥、算法和证书。还必须记录密钥在系统中可以和不可以使用的位置，以及可以和不可以使用密钥保护的数据类型。
V11.1.3 验证使用密码学发现机制来识别系统中所有密码学实例，包括加密、哈希和签名操作。
V11.1.4 验证维护密码学清单。这必须包含一个记录的计划，概述向新密码学标准（如后量子密码学）迁移的路径，以应对未来威胁。

V11.2 安全密码学实现（Secure Cryptography Implementation）

编号 要求
V11.2.1 验证密码操作使用行业验证的实现（包括库和硬件加速实现）。
V11.2.2 验证应用设计具有密码敏捷性，使随机数、认证加密、MAC 或哈希算法、密钥长度、轮数、密码和模式可以随时重新配置、升级或替换，以防止密码学突破。同样，必须能够替换密钥和密码并重新加密数据。这将允许在高可靠性的经批准 PQC 方案或标准的实现广泛可用后，无缝升级到后量子密码学（PQC）。
V11.2.3 验证所有密码原语基于算法、密钥大小和配置利用至少 128 位安全性。例如，256 位 ECC 密钥提供约 128 位安全性，而 RSA 需要 3072 位密钥才能达到 128 位安全性。
V11.2.4 验证所有密码操作是常量时间的，在比较、计算或返回中没有"短路"操作，以避免泄露信息。
V11.2.5 验证所有密码模块安全失败，错误的处理方式不会启用漏洞（如 Padding Oracle 攻击）。

V11.3 加密算法（Encryption Algorithms）

编号 要求
V11.3.1 验证不使用不安全的块模式（如 ECB）和弱填充方案（如 PKCS#1 v1.5）。
V11.3.2 验证仅使用经批准的密码和模式（如 AES-GCM）。
V11.3.3 验证加密数据通过使用经批准的认证加密方法或组合经批准的加密方法与经批准的 MAC 算法来防止未授权修改。
V11.3.4 验证随机数（nonce）、初始化向量和其他一次性数字不会用于多个加密密钥和数据元素对。生成方法必须适合所使用的算法。
V11.3.5 验证加密算法和 MAC 算法的任何组合都以先加密后 MAC（encrypt-then-MAC）模式运行。

V11.4 哈希和基于哈希的函数（Hashing and Hash-based Functions）

编号 要求
V11.4.1 验证通用密码学用例仅使用经批准的哈希函数，包括数字签名、HMAC、KDF 和随机位生成。不允许的哈希函数（如 MD5）不得用于任何密码学目的。
V11.4.2 验证密码使用经批准的、计算密集型的密钥派生函数（也称为"密码哈希函数"）存储，参数设置基于当前指南配置。设置应平衡安全性和性能，使暴力破解攻击对所需安全级别具有足够的挑战性。
V11.4.3 验证数字签名中使用的哈希函数作为数据认证或数据完整性的一部分具有抗碰撞性和适当的位长度。如果需要抗碰撞性，输出长度必须至少为 256 位。如果仅需要抗第二原像攻击，输出长度必须至少为 128 位。
V11.4.4 验证当从密码派生密钥时，应用使用经批准的具有密钥拉伸参数的密钥派生函数。使用中的参数必须平衡安全性和性能，以防止暴力破解攻击破坏生成的加密密钥。

V11.5 随机值（Random Values）

编号 要求
V11.5.1 验证所有旨在不可猜测的随机数和字符串必须使用加密安全伪随机数生成器（CSPRNG）生成，并具有至少 128 位的熵值。注意 UUID 不满足此条件。
V11.5.2 验证使用的随机数生成机制设计为即使在高负载下也能安全工作。

V11.6 公钥密码学（Public Key Cryptography）

编号 要求
V11.6.1 验证密钥生成和种子设定以及数字签名生成和验证仅使用经批准的密码算法和操作模式。密钥生成算法不得生成易受已知攻击的不安全密钥（例如易受费马因式分解的 RSA 密钥）。
V11.6.2 验证密钥交换使用经批准的密码算法（如 Diffie-Hellman），重点确保密钥交换机制使用安全参数。这将防止对密钥建立过程的攻击，这些攻击可能导致中间人攻击或密码学突破。

V11.7 使用中数据密码学（In-Use Data Cryptography）

编号 要求
V11.7.1 验证使用全内存加密来保护使用中的敏感数据，防止未授权用户或进程的访问。
V11.7.2 验证数据最小化确保在处理期间暴露最少量的数据，并确保数据在使用后立即或尽可能快地加密。

V12 安全通信

V12.1 通用 TLS 安全指南（General TLS Security Guidance）

编号 要求
V12.1.1 验证仅启用最新推荐版本的 TLS 协议（如 TLS 1.2 和 TLS 1.3）。最新版本的 TLS 协议必须是首选选项。
V12.1.2 验证仅启用推荐的密码套件，最强的密码套件设置为首选。L3 应用必须仅支持提供前向保密的密码套件。
V12.1.3 验证应用在使用证书身份进行认证或授权之前，验证 mTLS 客户端证书是否受信任。
V12.1.4 验证启用并配置了适当的证书吊销机制，如在线证书状态协议（OCSP）Stapling。
V12.1.5 验证在应用的 TLS 设置中启用了加密客户端 Hello（ECH），以防止在 TLS 握手过程中暴露敏感元数据（如服务器名称指示 SNI）。

V12.2 面向外部服务的 HTTPS 通信（HTTPS Communication with External Facing Services）

编号 要求
V12.2.1 验证客户端与面向外部的基于 HTTP 的服务之间的所有连接都使用 TLS，且不回退到不安全或未加密的通信。
V12.2.2 验证面向外部的服务使用公开受信任的 TLS 证书。

V12.3 通用服务间通信安全（General Service to Service Communication Security）

编号 要求
V12.3.1 验证所有入站和出站连接（包括监控系统、管理工具、远程访问和 SSH、中间件、数据库、大型机、合作伙伴系统或外部 API）都使用加密协议（如 TLS）。服务器不得回退到不安全或未加密的协议。
V12.3.2 验证 TLS 客户端在与 TLS 服务器通信之前验证收到的证书。
V12.3.3 验证应用内部基于 HTTP 的服务之间的所有连接都使用 TLS 或其他适当的传输加密机制，且不回退到不安全或未加密的通信。
V12.3.4 验证内部服务之间的 TLS 连接使用受信任的证书。当使用内部生成或自签名证书时，消费服务必须配置为仅信任特定的内部 CA 和特定的自签名证书。
V12.3.5 验证系统内部通信的服务（服务间通信）使用强认证以确保每个端点得到验证。必须使用强认证方法（如 TLS 客户端认证），使用公钥基础设施和抗重放攻击的机制。对于微服务架构，考虑使用服务网格来简化证书管理并增强安全性。

V13 配置

V13.1 配置文档（Configuration Documentation）

编号 要求
V13.1.1 验证应用的所有通信需求已记录。这必须包括应用依赖的外部服务以及终端用户可能提供外部位置供应用连接的情况。
V13.1.2 验证对于应用使用的每个服务，文档定义了最大并发连接数（如连接池限制）以及达到该限制时应用的行为（包括任何回退或恢复机制），以防止拒绝服务条件。
V13.1.3 验证应用文档定义了其使用的每个外部系统或服务的资源管理策略（如数据库、文件句柄、线程、HTTP 连接）。这应包括资源释放程序、超时设置、失败处理，以及在实施重试逻辑的地方指定重试限制、延迟和退避算法。对于同步 HTTP 请求-响应操作，应规定短超时并禁用重试或严格限制重试以防止级联延迟和资源耗尽。
V13.1.4 验证应用文档定义了对应用安全至关重要的密钥，以及基于组织威胁模型和业务需求的轮换计划。

V13.2 后端通信配置（Backend Communication Configuration）

编号 要求
V13.2.1 验证不支持应用标准用户会话机制的后端应用组件之间的通信（包括 API、中间件和数据层）经过认证。认证必须使用单独的服务账户、短期令牌或基于证书的认证，而不是不变的凭证（如密码、API 密钥或具有特权访问的共享账户）。
V13.2.2 验证后端应用组件之间的通信（包括本地或操作系统服务、API、中间件和数据层）使用分配了最低必要权限的账户执行。
V13.2.3 验证如果必须使用凭证进行服务认证，则消费者使用的凭证不是默认凭证（如 root/root 或 admin/admin）。
V13.2.4 验证使用允许列表来定义应用允许通信的外部资源或系统（如出站请求、数据加载或文件访问）。此允许列表可以在应用层、Web 服务器、防火墙或不同层的组合中实现。
V13.2.5 验证 Web 或应用服务器配置了资源或系统的允许列表，限制服务器可以向其发送请求或加载数据或文件的目标。
V13.2.6 验证当应用连接到独立的服务时，遵循每个连接的已记录配置，如最大并行连接数、达到最大允许连接数时的行为、连接超时和重试策略。

V13.3 密钥管理（Secret Management）

编号 要求
V13.3.1 验证使用密钥管理解决方案（如密钥保管库）来安全创建、存储、控制访问和销毁后端密钥。这些可能包括密码、密钥材料、与数据库和第三方系统的集成、基于时间令牌的密钥和种子、其他内部密钥和 API 密钥。密钥不得包含在应用源代码中或包含在构建产物中。对于 L3 应用，必须涉及基于硬件的解决方案（如 HSM）。
V13.3.2 验证对密钥资产的访问遵循最小权限原则。
V13.3.3 验证所有密码操作都使用隔离的安全模块（如保管库或硬件安全模块）执行，以安全管理和保护密钥材料免受安全模块外部的暴露。
V13.3.4 验证密钥配置为根据应用文档过期和轮换。

V13.4 意外信息泄露（Unintended Information Leakage）

编号 要求
V13.4.1 验证应用部署时不包含任何源代码控制元数据（包括 .git 或 .svn 文件夹），或以这些文件夹对外部和应用本身都不可访问的方式部署。
V13.4.2 验证生产环境中所有组件的调试模式已禁用，以防止暴露调试功能和信息泄露。
V13.4.3 验证 Web 服务器不会向客户端暴露目录列表，除非有明确意图。
V13.4.4 验证生产环境中不支持使用 HTTP TRACE 方法，以避免潜在的信息泄露。
V13.4.5 验证文档（如内部 API 文档）和监控端点未被暴露，除非有明确意图。
V13.4.6 验证应用不会暴露后端组件的详细版本信息。
V13.4.7 验证 Web 层配置为仅提供具有特定文件扩展名的文件，以防止意外的信息、配置和源代码泄露。

V14 数据保护

V14.1 数据保护文档（Data Protection Documentation）

编号 要求
V14.1.1 验证应用创建和处理的所有敏感数据已被识别并分类到保护级别。这包括仅编码因此容易解码的数据（如 Base64 字符串或 JWT 内的明文载荷）。保护级别需要考虑应用需要遵守的任何数据保护和隐私法规及标准。
V14.1.2 验证所有敏感数据保护级别都有记录的保护要求集。这必须包括（但不限于）与通用加密、完整性验证、保留、数据记录方式、日志中敏感数据的访问控制、数据库级加密、隐私和隐私增强技术的使用以及其他保密要求相关的要求。

V14.2 通用数据保护（General Data Protection）

编号 要求
V14.2.1 验证敏感数据仅在 HTTP 消息体或头字段中发送到服务器，URL 和查询字符串不包含敏感信息（如 API 密钥或会话令牌）。
V14.2.2 验证应用防止敏感数据被缓存在服务器组件（如负载均衡器和应用缓存）中，或确保数据在使用后被安全清除。
V14.2.3 验证定义的敏感数据不被发送到不受信任的方（如用户追踪器），以防止在应用控制之外的数据被不当收集。
V14.2.4 验证围绕敏感数据的加密、完整性验证、保留、数据记录方式、日志中敏感数据的访问控制、隐私和隐私增强技术的控制措施按照特定数据保护级别的文档实施。
V14.2.5 验证缓存机制配置为仅缓存具有该资源预期内容类型且不包含敏感动态内容的响应。当访问不存在的文件时，Web 服务器应返回 404 或 302 响应，而非返回不同的有效文件。这应防止 Web 缓存欺骗攻击。
V14.2.6 验证应用仅为应用功能返回最低要求的敏感数据。例如，仅返回信用卡号的部分数字而非完整号码。如果需要完整数据，应在用户界面中进行掩码处理，除非用户特别查看。
V14.2.7 验证敏感信息遵循数据保留分类，确保在定义的时间表上或根据情况需要自动删除过时或不必要的数据。
V14.2.8 验证从用户提交文件的元数据中删除敏感信息，除非用户同意存储。

V14.3 客户端数据保护（Client-side Data Protection）

编号 要求
V14.3.1 验证认证数据在客户端或会话终止后从客户端存储（如浏览器 DOM）中清除。Clear-Site-Data HTTP 响应头字段可能有助于此，但客户端也应能在会话终止时服务器连接不可用时进行清理。
V14.3.2 验证应用设置了充分的反缓存 HTTP 响应头字段（即 Cache-Control: no-store），以防止敏感数据被浏览器缓存。
V14.3.3 验证存储在浏览器存储中的数据（如 localStorage、sessionStorage、IndexedDB 或 Cookie）不包含敏感数据，会话令牌除外。

V15 安全编码和架构

V15.1 安全编码和架构文档（Secure Coding and Architecture Documentation）

编号 要求
V15.1.1 验证应用文档定义了基于风险的第三方组件有漏洞版本的修复时间框架，以及通用库更新时间框架，以最小化这些组件的风险。
V15.1.2 验证维护库存目录（如软件物料清单 SBOM），包括所有使用中的第三方库，包括验证组件来自预定义的、受信任的且持续维护的仓库。
V15.1.3 验证应用文档识别了耗时或资源密集的功能。这必须包括如何防止由于过度使用此功能导致的可用性丧失，以及如何避免构建响应的时间超过消费者的超时时间。潜在的防御措施可能包括异步处理、使用队列以及限制每用户和每应用的并行进程数。
V15.1.4 验证应用文档突出显示被认为是"风险组件"的第三方库。
V15.1.5 验证应用文档突出显示正在使用"危险功能"的应用部分。

V15.2 安全架构和依赖（Security Architecture and Dependencies）

编号 要求
V15.2.1 验证应用仅包含未超过记录的更新和修复时间框架的组件。
V15.2.2 验证应用基于记录的安全决策和策略实施了防御措施，以防止由于耗时或资源密集的功能导致的可用性丧失。
V15.2.3 验证生产环境仅包含应用运行所需的功能，不暴露多余功能（如测试代码、示例片段和开发功能）。
V15.2.4 验证第三方组件及其所有传递依赖来自预期的仓库（无论是内部拥有还是外部来源），且不存在依赖混淆攻击的风险。
V15.2.5 验证应用围绕记录为包含"危险功能"或使用被认为是"风险组件"的第三方库的部分实施了额外保护。这可能包括沙箱化、封装、容器化或网络级隔离等技术，以延迟和阻止攻击者在攻陷应用一部分后转向应用其他部分。

V15.3 防御性编码（Defensive Coding）

编号 要求
V15.3.1 验证应用仅返回数据对象的必要子集字段。例如，不应返回整个数据对象，因为某些字段不应对用户可访问。
V15.3.2 验证当应用后端调用外部 URL 时，配置为不跟随重定向，除非这是预期的功能。
V15.3.3 验证应用通过限制每个控制器和操作的允许字段来防御批量赋值攻击，例如，不可能在非预期为该操作一部分的字段中插入或更新值。
V15.3.4 验证所有代理和中间件组件使用不能被终端用户操纵的受信任数据字段正确传递用户的原始 IP 地址，且应用和 Web 服务器使用此正确值进行日志记录和安全决策（如速率限制），同时考虑到即使原始 IP 地址也可能由于动态 IP、VPN 或企业防火墙而不可靠。
V15.3.5 验证应用显式确保变量类型正确，并执行严格的相等和比较操作。这是为了避免由于应用代码对变量类型做出假设而导致的类型篡改或类型混淆漏洞。
V15.3.6 验证 JavaScript 代码以防止原型污染的方式编写，例如使用 Set() 或 Map() 代替对象字面量。
V15.3.7 验证应用具有防御 HTTP 参数污染攻击的机制，特别是当应用框架不区分请求参数的来源（查询字符串、请求体参数、Cookie 或头字段）时。

V15.4 安全并发（Safe Concurrency）

编号 要求
V15.4.1 验证多线程代码中的共享对象（如缓存、文件或多线程访问的内存对象）通过使用线程安全类型和同步机制（如锁或信号量）安全访问，以避免竞态条件和数据损坏。
V15.4.2 验证对资源状态的检查（如存在性或权限）及依赖于它们的操作作为单个原子操作执行，以防止检查时间到使用时间（TOCTOU）竞态条件。例如，在打开文件之前检查文件是否存在，或在授予访问权限之前验证用户的访问权。
V15.4.3 验证一致使用锁以避免线程卡住（无论是相互等待还是无限重试），且锁定逻辑保持在负责管理资源的代码内，以确保锁不会被外部类或代码无意或恶意修改。
V15.4.4 验证资源分配策略通过确保对资源的公平访问来防止线程饥饿，例如利用线程池，允许低优先级线程在合理的时间范围内继续执行。

V16 安全日志和错误处理

V16.1 安全日志文档（Security Logging Documentation）

编号 要求
V16.1.1 验证存在一份清单，记录应用技术栈每一层执行的日志、正在记录的事件、日志格式、日志存储位置、使用方式、访问控制方式以及日志保留时长。

V16.2 通用日志（General Logging）

编号 要求
V16.2.1 验证每个日志条目包含必要的元数据（如时间、地点、谁、什么），以便在事件发生时进行详细的时间线调查。
V16.2.2 验证所有日志组件的时间源已同步，且安全事件元数据中的时间戳使用 UTC 或包含明确的时区偏移。建议使用 UTC 以确保分布式系统间的一致性并防止夏令时转换期间的混淆。
V16.2.3 验证应用仅将日志存储或广播到日志清单中记录的文件和服务。
V16.2.4 验证日志可以被使用中的日志处理器读取和关联，最好使用通用的日志格式。
V16.2.5 验证记录敏感数据时，应用基于数据的保护级别执行日志记录。例如，可能不允许记录某些数据（如凭证或支付详情）。其他数据（如会话令牌）可能仅通过全部或部分哈希或掩码方式记录。

V16.3 安全事件（Security Events）

编号 要求
V16.3.1 验证所有认证操作都被记录，包括成功和失败的尝试。还应收集额外元数据，如认证类型或使用的因素。
V16.3.2 验证失败的授权尝试被记录。对于 L3，必须包括记录所有授权决策，包括敏感数据被访问时的记录（不记录敏感数据本身）。
V16.3.3 验证应用记录文档中定义的安全事件，并记录绕过安全控制的尝试（如输入验证、业务逻辑和反自动化）。
V16.3.4 验证应用记录意外错误和安全控制失败（如后端 TLS 失败）。

V16.4 日志保护（Log Protection）

编号 要求
V16.4.1 验证所有日志组件适当编码数据以防止日志注入。
V16.4.2 验证日志受到保护，防止未授权访问且不能被修改。
V16.4.3 验证日志安全传输到逻辑上独立的系统进行分析、检测、告警和升级。目的是确保如果应用被攻破，日志不会被同时破坏。

V16.5 错误处理（Error Handling）

编号 要求
V16.5.1 验证当发生意外或安全敏感错误时，向消费者返回通用消息，确保不暴露敏感的内部系统数据（如堆栈跟踪、查询、密钥和令牌）。
V16.5.2 验证当外部资源访问失败时，应用能继续安全运行，例如使用断路器或优雅降级等模式。
V16.5.3 验证应用优雅且安全地失败，包括异常发生时，防止失败开放条件（如尽管验证逻辑产生错误仍处理交易）。
V16.5.4 验证定义了"最后手段"错误处理器来捕获所有未处理的异常。这既是为了避免丢失必须写入日志文件的错误详情，也是为了确保错误不会导致整个应用进程崩溃，从而导致可用性丧失。

V17 WebRTC

V17.1 TURN 服务器（TURN Server）

编号 要求
V17.1.1 验证 TURN（Traversal Using Relays around NAT）服务仅允许访问非保留用于特殊目的（如内部网络、广播、环回）的 IP 地址。注意这同时适用于 IPv4 和 IPv6 地址。
V17.1.2 验证当合法用户尝试在 TURN 服务器上打开大量端口时，TURN 服务不会受到资源耗尽的影响。

V17.2 媒体（Media）

编号 要求
V17.2.1 验证 DTLS（Datagram Transport Layer Security）证书的密钥根据记录的密钥管理策略进行管理和保护。
V17.2.2 验证媒体服务器配置为使用和支持经批准的 DTLS 密码套件以及用于建立安全实时传输协议密钥的 DTLS 扩展（DTLS-SRTP）的安全保护配置文件。
V17.2.3 验证在媒体服务器检查 SRTP（Secure Real-time Transport Protocol）认证，以防止 RTP 注入攻击导致拒绝服务条件或将音视频媒体插入媒体流。
V17.2.4 验证媒体服务器在遇到格式错误的 SRTP 包时能继续处理传入的媒体流量。
V17.2.5 验证媒体服务器在来自合法用户的 SRTP 包洪水期间能继续处理传入的媒体流量。
V17.2.6 验证媒体服务器不受 DTLS 中"ClientHello"竞态条件漏洞的影响，通过检查媒体服务器是否已知存在此漏洞或执行竞态条件测试来验证。
V17.2.7 验证与媒体服务器关联的任何音视频录制机制在来自合法用户的 SRTP 包洪水期间能继续处理传入的媒体流量。
V17.2.8 验证 DTLS 证书根据 SDP（Session Description Protocol）指纹属性进行检查，如果检查失败则终止媒体流，以确保媒体流的真实性。

V17.3 信令（Signaling）

编号 要求
V17.3.1 验证信令服务器在洪水攻击期间能继续处理合法的传入信令消息。这应通过在信令级别实施速率限制来实现。
V17.3.2 验证信令服务器在遇到可能导致拒绝服务条件的格式错误的信令消息时，能继续处理合法的信令消息。这可能包括实施输入验证、安全处理整数溢出、防止缓冲区溢出以及使用其他健壮的错误处理技术。