Windows 应用认证工具包测试

项目
06/13/2023

下面是认证桌面应用的测试详细信息。有关信息，请参阅使用 Windows 应用认证工具包。

清理可逆安装
安装到正确的文件夹测试
数字签名文件测试
支持 x64 Windows 测试
OS 版本检查测试
用户帐户控制 (UAC) 测试
遵循系统重启管理器消息
安全模式测试
多用户会话测试
崩溃和挂起测试
兼容性和复原能力测试
Windows 安全中心最佳做法测试
Windows 安全功能测试
高 DPI 测试

清理可逆安装

安装和卸载应用并检查剩余文件和注册表项。

背景
- 干净、可逆的安装使用户能够部署和删除应用。若要通过此测试，应用必须执行以下操作：
  - 安装或卸载应用后，应用不会强制系统立即重启。 应用的安装或卸载过程不应要求在完成后立即重启系统。如果这需要重启系统，则用户应该能够在方便时重启系统。
  - 该应用不依赖于 SFN) (8.3 短文件名。 应用的安装和卸载过程必须能够使用长文件名和文件夹路径。
  - 应用不会阻止无提示安装/卸载
  - 应用在系统注册表中制作所需的条目。 Windows 清单工具和遥测工具需要有关已安装应用的完整信息。应用安装程序必须创建正确的注册表项才能成功检测和卸载。
- 如果使用基于 MSI 的安装程序，MSI 会自动创建以下注册表项。如果不使用 MSI 安装程序，则安装模块必须在安装过程中创建以下注册表项：
  - DisplayName
  - InstallLocation
  - Publisher
  - UninstallString
  - VersionMajor 或 MajorVersion
  - VersionMinor 或 MinorVersion
- 应用必须在“添加/删除程序”中删除其所有条目。
测试详细信息
- 此测试检查应用的安装和卸载过程是否存在所需的行为。
纠正措施
- 根据上述要求查看应用的设计和行为。

安装到正确的文件夹测试

验证应用是否将其程序和数据文件写入正确的文件夹。

背景
- 应用必须正确使用系统和每用户文件夹，以便可以访问所需的数据和设置，同时保护用户的数据和设置免受未经授权的访问。
Program Files 文件夹
- 默认情况下，对于本机 32 位和 64 位应用，应用必须安装在 Program Files 文件夹中 (%ProgramFiles%，对于在 x64) 上运行的 32 位应用，必须安装 %ProgramFiles (x86) %。
- 注意： 由于为此文件夹配置了安全权限，应用不得将用户数据或应用数据存储在 Program Files 文件夹中。
- Windows 系统文件夹上的 ACL 仅允许管理员帐户读取和写入这些文件夹。因此，标准用户帐户将无权访问这些文件夹。但是，文件虚拟化允许应用将文件（如配置文件）存储在通常只能由管理员写入的系统位置。在这种情况下，如果程序无法访问所需的文件，则以标准用户身份运行程序可能会导致失败。
- 应用应使用已知文件夹来确保能够访问其数据。
- 注意： Windows 提供文件虚拟化以提高应用兼容性，并消除应用在 Windows 上以标准用户身份运行时出现的问题。你的应用不应依赖于未来版本的 Windows 中存在的虚拟化。
用户特定的应用数据文件夹
- 在“每台计算机”安装中，应用不得在安装期间写入特定于用户的数据。仅当用户首次启动应用时，才应写入特定于用户的安装数据。这是因为安装时没有正确的用户位置来存储数据。安装后，应用尝试在计算机级别修改默认关联行为将失败。相反，必须在每用户级别声明默认值，这可以防止多个用户覆盖彼此的默认值。
- 所有特定于特定用户且不与计算机其他用户共享的应用数据都必须存储在 Users\username>\<AppData 中。
- 必须在计算机上的用户之间共享的所有应用数据都应存储在 ProgramData 中。
其他系统文件夹和注册表项
- 应用绝不应直接写入 Windows 目录和或子目录。使用正确的方法将文件（如字体或驱动程序）安装到这些目录。
- 应用不应在启动时自动启动，例如将条目添加到以下一个或多个位置：
  - 在 Software\Microsoft\Windows\CurrentVersion 下，注册表运行项 HKLM 和或 HKCU
  - Software\Wow6432Node\Microsoft\windows\CurrentVersion 下的注册表运行项 HKLM 和或 HKCU
  - “开始”菜单全部程序 > 启动
测试详细信息
- 此测试验证应用是否使用 Windows 提供的文件系统中的特定位置来存储程序和软件组件、共享应用数据以及特定于用户的应用数据。
更正操作
- 查看应用如何使用系统的文件夹，并确保其正确使用它们。
例外和豁免
- 对于写入全局程序集缓存的桌面应用， (GAC) (.NET 应用应将程序集依赖项保密，并将其存储在应用的目录中，除非明确要求) 共享程序集。
- 安装到“程序文件”文件夹不是桌面 SW 包实现 SW 徽标的要求，仅在“SW 基础知识”类别下。

数字签名文件测试

测试可执行文件和设备驱动程序，以验证它们是否具有有效的数字签名。

背景
- 使用数字签名的文件可以验证文件是否为正版，并检测文件是否已被篡改。
- 强制实施内核模式代码签名是一项 Windows 功能，也称为代码完整性 (CI) 。 CI 通过在每次将文件加载到内存时验证文件的完整性来提高 Windows 的安全性。 CI 检测恶意代码是否修改了系统二进制文件，并在内核模块的签名无法正确验证时生成诊断和系统审核日志事件。
- 如果应用需要提升的权限，提升提示将显示有关请求提升访问权限的可执行文件的上下文信息。根据应用是否经过 Authenticode 签名，用户可能会看到同意提示或凭据提示。
- 强名称可防止第三方欺骗你的代码，前提是你保护私钥。 .NET Framework在加载程序集或将其安装在 GAC 中时验证数字签名。如果无法访问私钥，恶意用户将无法修改代码并再次对其进行签名。
测试详细信息
- 所有可执行文件（例如文件扩展名为 .exe、.dll、.ocx、.sys、.cpl、.drv 和 .scr 的文件）都必须使用 Authenticode 证书进行签名。
- 应用安装的所有内核模式驱动程序都必须具有通过 WHQL 或 DRS 程序获取的 Microsoft 签名。所有文件系统筛选器驱动程序都必须经过 WHQL 签名。
纠正措施
- 对应用的可执行文件进行签名。
- 使用 makecert.exe 生成证书或从商业证书颁发机构之一获取代码签名密钥， (CA) ，例如 VeriSign、Thawte 或 Microsoft CA。
例外和豁免
- 仅对未签名的第三方可再发行组件考虑豁免。若要授予此豁免，需要一份通信证明，请求签名版本的可再发行 () 。
- 设备增值软件包不受内核模式驱动程序认证，因为驱动程序必须通过 Windows 硬件认证进行认证。

支持 x64 Windows 测试

测试应用，确保.exe是为要安装它的平台体系结构构建的。

背景
- 可执行文件必须针对安装它的处理器体系结构生成。某些可执行文件可能在不同的处理器体系结构上运行，但这并不可靠。
- 体系结构兼容性非常重要，因为 32 位进程无法加载 64 位 DLL，64 位进程无法加载 32 位 DLL。同样，64 位版本的 Windows 不支持运行基于 16 位 Windows 的应用程序，因为句柄在 64 位 Windows 上具有 32 个有效位，因此无法将其传递给 16 位应用程序。因此，尝试在 64 位版本的 Windows 上启动 16 位应用程序会失败。
- 32 位设备驱动程序无法在 64 位版本的 Windows 上运行，因此必须将其移植到 64 位体系结构。
- 对于用户模式应用程序，64 位 Windows 包括 WOW64，它使 32 位 Windows 应用程序能够在运行 64 位 Windows 的系统上执行，尽管会降低一些性能。设备驱动程序不存在等效的转换层。
- 若要保持与 64 位版本的 Windows 的兼容性，应用必须本机支持 64 位，或者至少基于 32 位 Windows 的应用必须在 64 位系统上无缝运行：
  - 应用及其安装程序不得包含任何 16 位代码或依赖于任何 16 位组件。
  - 应用安装程序必须在 64 位版本的 Windows 上检测并安装正确的驱动程序和组件。
  - 任何 shell 插件都必须在 64 位版本的 Windows 上运行。
  - 在 WoW64 模拟器下运行的应用不应尝试绕过 Wow64 虚拟化机制。如果应用需要检测它们是否在 WoW64 模拟器中运行的特定方案，则应通过调用 IsWow64Process 来执行此操作。
测试详细信息
- 应用不应安装任何 16 位二进制文件。如果应用应在 64 位计算机上运行，则不应安装 32 位内核模式驱动程序。
纠正措施
- 为要为其安装它们的处理器体系结构生成可执行文件和驱动程序。

OS 版本检查测试

测试应用如何检查运行它的 Windows 版本。

背景
- 应用检查操作系统版本，方法是测试大于或等于所需版本的版本，以确保与 Windows 的未来版本兼容。
测试详细信息
- 模拟在不同版本的 Windows 上运行应用，以查看其反应方式。
更正操作
- 通过测试当前版本是否大于或等于应用、服务或驱动程序所需的版本来测试正确的 Windows 版本。
- 驱动程序安装程序和卸载模块不得检查操作系统版本。
例外和豁免
- 对于满足以下条件的应用，将考虑豁免： (仅适用于桌面应用认证)
  - 应用作为一个包提供，在 Windows XP、Windows Vista 和 Windows 7 上运行，并且需要检查操作系统版本来确定在给定操作系统上安装哪些组件。
  - 仅检查操作系统最低版本的应用仅在安装期间 (，而不是在运行时) 仅使用批准的 API 调用，并根据需要在应用清单中列出最低版本要求。
  - 安全应用（如防病毒和防火墙应用）、系统实用工具（如碎片整理实用工具和备份应用）以及仅使用已批准的 API 调用检查 OS 版本的诊断工具。

用户帐户控制 (UAC) 测试

测试应用以验证它是否不需要不必要的提升权限来运行。

背景
- 仅当用户是管理员时才运行或安装的应用强制用户使用不必要的提升权限运行应用，这可能会允许恶意软件进入用户的计算机。
- 当始终强制用户使用提升的访问令牌运行应用时，应用可以服务器作为欺骗性或恶意代码的入口点。此恶意软件很容易修改操作系统，或者更糟的是，影响其他用户。几乎不可能控制具有完全管理员访问权限的用户，因为管理员可以在计算机上安装应用并运行任何应用或脚本。 IT 经理一直在寻求创建“标准桌面”的方法，以便用户以标准用户身份登录。标准桌面可大幅降低技术支持成本并降低 IT 开销。
- 大多数应用程序在运行时不需要管理员权限。标准用户帐户应该能够运行它们。 Windows 应用必须具有 (嵌入式或外部) 的清单，以定义其执行级别，告知 OS 运行应用所需的权限。应用清单仅适用于.exe文件，不适用于.dll文件。用户帐户控制 (UAC) 不会在创建进程期间检查 DLL。 UAC 规则不适用于 Microsoft 服务。应用清单可以是嵌入的，也可以是外部的。
- 若要创建清单，请创建名为 <app_name>.exe.manifest 的文件，并将其存储在 EXE 所在的目录中。请注意，如果应用具有内部清单，则忽略任何外部清单。
  - 例如， <requestedExecutionLevel level=“”asInvoker | highestAvailable | requireAdministrator“” uiAccess=“”true|false“”/>
  - 应用的main过程必须以标准用户身份运行 (作为Invoker) 。必须将任何管理功能移动到使用管理权限运行的单独进程中。
  - 需要提升的权限的面向用户的应用必须经过 Authenticode 签名。
测试详细信息
- 面向用户的 exes 应标记为 asInvoker 属性。如果它们被标记为 highestAvailable 或 requireAdministrator，则它们应正确进行验证码签名。任何应用 exe 不应将 uiAccess 属性设置为 true。作为服务运行的任何 exe 都从此特定检查中排除。
更正操作
- 查看应用的清单文件，了解正确的条目和权限级别。
例外和豁免
- 对于使用提升的权限运行其main进程的应用，需要豁免 (requireAdministrator 或 highestAvailable) 。 main进程是向用户提供应用入口点的进程。
- 对于以下情况，将考虑豁免：
  - 执行级别设置为 highestAvailable 和/或 requireAdministrator 的管理或系统工具。
  - 只有辅助功能或 UI 自动化框架应用将 uiAccess 标志设置为 TRUE，以绕过 UIPI) (用户界面特权隔离。若要正确启动应用利用率，此标志必须是验证码签名的，并且必须驻留在文件系统中的受保护位置，例如 Program Files。

遵循系统重启管理器消息

测试应用如何响应系统关闭和重启消息。

背景
- 应用在收到系统正在关闭的通知时，必须尽快退出，以便为用户提供响应式关机或关机体验。
- 在严重关闭中，返回 FALSE WM_QUERYENDSESSION 的应用将 WM_ENDSESSION 并关闭，而响应WM_QUERYENDSESSION超时的应用将被强制终止。
测试详细信息
- 检查应用如何响应关闭和退出消息。
更正操作
- 如果你的应用未通过此测试，请查看它如何处理这些 Windows 消息：
  - 使用LPARAM = ENDSESSION_CLOSEAPP (0x1) WM_QUERYENDSESSION：桌面应用必须立即响应 (TRUE) ，以备重启。控制台应用可以调用 SetConsoleCtrlHandler 来接收关闭通知。服务可以调用 RegisterServiceCtrlHandlerEx 以在处理程序例程中接收关闭通知。
  - 使用LPARAM = ENDSESSION_CLOSEAPP (0x1) WM_ENDSESSION：应用必须在 30 秒内返回 0 值并关闭。应用至少应通过保存任何用户数据来准备，并声明重启后所需的信息。
- 接收 CTRL_C_EVENT 通知的控制台应用应立即关闭。驱动程序不得否决系统关闭事件。
- 注意： 由于无法中断的操作而必须阻止关闭的应用应使用 ShutdownBlockReasonCreate 注册一个向用户解释原因的字符串。操作完成后，应用应调用 ShutdownBlockReasonDestroy 以指示可以关闭系统。

安全模式测试

测试驱动程序或服务是否配置为在安全模式下启动。

背景
- 安全模式允许用户诊断和排查 Windows 问题。只有操作系统基本操作或提供诊断和恢复服务所需的驱动程序和服务才应在安全模式下加载。在安全模式下加载其他文件会使解决操作系统问题变得更加困难。
- 默认情况下，只有预装 Windows 的驱动程序和服务才能在安全模式下启动。应禁用所有其他驱动程序和服务，除非系统要求它们用于基本操作或诊断和恢复目的。
测试详细信息
- 应用安装的驱动程序不应标记为在安全模式下加载。
更正操作
- 如果驱动程序或服务不应在安全模式下启动，请从注册表项中删除应用的条目。
例外和豁免
- 必须在安全模式下启动的驱动程序和服务需要获得豁免认证。豁免请求必须包括要添加到 SafeBoot 注册表项的每个驱动程序和服务，并描述驱动程序或服务必须在安全模式下运行的技术原因。应用安装程序必须在以下注册表项中注册所有此类驱动程序和服务：
  - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
  - HKLM/System/CurrentControlSet/Control/SafeBoot/Network
注意： 必须测试要在安全模式下启动的驱动程序和服务，以确保它们在安全模式下正常运行，而不会发生任何错误。

多用户会话测试

测试应用在多个会话中同时运行时的行为方式。

背景
- Windows 用户必须能够运行并发会话。应用必须确保当它们在本地或远程多个会话中运行时，应用的正常功能不会受到不利影响。应用设置和数据文件必须特定于用户，并且用户的隐私和首选项必须限制为用户的会话。
测试详细信息
- 运行应用的多个并发实例以测试以下各项：
  - 同时运行的应用的多个实例彼此隔离。
- 这意味着一个实例中的用户数据对另一个实例不可见。不应在活动用户会话中听到非活动用户会话中的声音。如果多个应用实例使用共享资源，则应用必须确保不存在冲突。
  - 如果为多个用户安装了应用，它将数据存储在正确的文件夹中， () 和注册表位置。
  - 应用可以在多个用户会话中运行， (快速用户切换) 进行本地和远程访问。
- 若要确保这一点，应用必须为应用的现有实例检查其他终端服务 (TS) 会话。如果应用不支持多个用户会话或远程访问，则必须在从此类会话启动时向用户明确说明这一点。
纠正措施
- 确保应用不会将系统范围的数据文件或设置存储在用户特定的数据存储中，例如 User Profile 或 HKCU。如果是，该信息将不可供其他用户使用。
- 应用必须在安装期间安装系统范围的配置和数据文件，并在用户运行应用时在安装后创建特定于用户的文件和设置。
- 确保应用不会在本地或远程阻止多个并发会话。应用不得依赖全局互斥体或其他命名对象来检查或阻止多个并发会话。
- 如果应用不允许每个用户多个并发会话，请对互斥体和其他命名对象使用每用户或每会话命名空间。

崩溃和挂起测试

在认证测试期间监视应用，记录它何时崩溃或停止响应。

背景
- 应用故障（如崩溃和挂起）对用户造成重大干扰，并造成挫折。消除此类故障可提高应用稳定性和可靠性，整体而言，为用户提供更好的应用体验。停止响应或崩溃的应用可能导致用户丢失数据和拥有糟糕的体验。
测试详细信息
- 在整个认证测试中，我们将测试应用的恢复能力和稳定性。
- Windows 应用认证工具包调用 IApplicationActivationManager：：ActivateApplication 来启动 Windows 应用商店应用。若要使 ActivateApplication 启动应用，必须启用用户帐户控制 (UAC) 并且屏幕分辨率必须至少为 1024 x 768 或 768 x 1024。如果不满足任何条件，那么你的应用将无法通过此测试。
纠正措施
- 确保在测试计算机上启用 UAC。
- 确保在屏幕足够大的计算机上运行测试。
- 如果你的应用无法启动并且你的测试平台满足 ActivateApplication 的先决条件，那么你可以通过查看激活事件日志来解决此问题。若要在事件日志中找到这些条目，请执行以下操作：
  1. 打开eventvwr.exe并导航到 \Windows 日志\应用程序节点。
  2. 筛选视图以显示事件 ID：5900-6000。
  3. 查看日志条目，了解可能说明了应用为何未启动的信息。
- 排除文件的问题，识别并修复问题。重新构建和重新测试应用。
其他资源

兼容性和复原能力测试

背景
- 此检查将验证应用的两个方面：应用main可执行 () 例如，面向用户的应用入口点必须进行清单，以便实现兼容性，以及声明正确的 GUID。为了支持此新测试，报表将在“兼容性 & 复原”下有一个子节点。如果缺少其中一个或两个条件，应用将失败。
测试详细信息
- 兼容性： 应用必须完全正常运行，而无需使用 Windows 兼容性模式、AppHelp 消息或其他兼容性修补程序。兼容性清单允许 Windows 在不同的操作系统版本下为应用提供适当的兼容性行为
- AppInit： 应用不得在HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs注册表项中列出要加载的 DLL。
- 切换回： 应用程序必须提供 switchback 清单。如果缺少清单，Windows 应用认证工具包会发出警告消息。 Windows 应用认证工具包还将验证清单是否包含有效的 OS GUID。
更正操作
- 修复使用兼容性修补程序的应用组件。
- 确保应用的功能不依赖于兼容性修补程序。
- 确保应用已清单化，并且兼容性部分包含适当的值
其他信息
- 有关详细信息，请参阅 AppInit DLL 。

Windows 安全中心最佳做法测试

背景
- 应用不应更改默认的 Windows 安全设置
测试详细信息
- 通过运行攻击面分析器来测试应用的安全性。方法是按每个测试添加失败类别。例如，安全测试的某些类别可能包括：
  - 初始化失败
  - 安全体系结构故障
  - 可能的缓冲区溢出失败
  - 崩溃失败
- 有关详细信息，请参阅此处。
更正操作
- 排查并修复测试发现的问题。重新构建和重新测试应用。

Windows 安全功能测试

背景
- 应用程序必须选择使用 Windows 安全功能。更改默认的 Windows 安全保护可能增加客户的风险。
测试详细信息
- 通过运行 BinScope Binary Analyzer 来测试应用的安全性。有关详细信息，请参阅此处。
更正操作
- 排查并修复测试发现的问题。重新构建和重新测试应用。

高 DPI 测试

强烈建议 Win32 应用能够感知 DPI。这是使应用 UI 在各种高 DPI 显示设置中保持良好外观的关键。在高 DPI 显示设置上运行的非 DPI 感知应用可能会出现问题，例如 UI 元素缩放不正确、文本剪裁和图像模糊。有两种方法可以声明应用为 DPI 感知。一种是声明 DPI。

背景
- 此检查将验证应用的两个方面，main可执行文件 () 例如，必须针对用户的应用入口点进行清单，以便获得高 DPI 感知，并且调用适当的 API 以支持高 DPI。如果缺少其中一个或两个条件，应用将失败。此检查将在桌面报表中引入一个新部分，请参阅以下示例。
测试详细信息
- 当我们检测到以下任何情况时，测试将生成警告：
  - main EXE 不在其清单中声明 DPI 感知，也不会调用 SetProcessDPIAware API。 (如果开发人员忘记) 添加 DPI 感知清单，请警告开发人员。
  - main EXE 不在其清单中声明 DPI 感知，但它调用 SetProcessDPIAware API (警告开发人员，他应使用清单来声明 DPI 感知，而不是调用 API) 。
  - mainEXE 在其清单中声明 DPI 感知，但它也调用 SetProcessDPIAware API (警告开发人员，) 调用该 API 没有必要。
  - 对于未main EXE 的二进制文件，如果它们调用 API，请发出警告 (不建议) 调用 API。
更正操作
- 不建议使用 SetProcessDPIAware () 函数。如果 DLL 在初始化期间缓存 DPI 设置，则调用应用中的 SetProcessDPIAware () 可能会生成争用条件。在 DLL 中调用 SetProcessDPIAware () 函数也不是一个好的做法。
其他信息
- 编写高 DPI 应用