下面是用于认证桌面应用的测试详细信息。 有关信息,请参阅 使用 Windows 应用认证工具包。
- 清理可逆安装
- 安装到正确的文件夹测试
- 数字签名文件测试
- 支持 x64 Windows 测试
- OS 版本检查测试
- 用户帐户控制(UAC)测试
- 遵循系统重启管理器消息
- 安全模式测试
- 多用户会话测试
- 崩溃并挂起测试
- 兼容性和复原能力测试
- Windows 安全最佳做法测试
- Windows 安全功能测试
- 高 DPI 测试
清理可逆安装
安装和卸载应用,并检查残差文件和注册表项。
- 背景
- 干净、可逆的安装使用户能够部署和删除应用。 若要通过此测试,应用必须执行以下作:
- 安装或卸载应用后,应用不会强制系统立即重启。 应用安装或卸载过程在完成后,绝不需要系统重启。 如果这要求重启系统,用户应能够在方便时重启系统。
- 该应用不依赖于 8.3 短文件名(SFN)。 应用的安装和卸载过程必须能够使用长文件名和文件夹路径。
- 应用不会阻止无提示安装/卸载
- 应用在系统注册表中输入所需的条目。 Windows 清单工具和遥测工具需要有关已安装应用的完整信息。 应用安装程序必须创建正确的注册表项才能成功检测和卸载。
- 如果使用基于 MSI 的安装程序,MSI 会自动创建下面的注册表项。 如果不使用 MSI 安装程序,安装模块必须在安装过程中创建以下注册表项:
- DisplayName
- InstallLocation
- 发行人
- UninstallString
- VersionMajor 或 MajorVersion
- VersionMinor 或 MinorVersion
- 应用必须在“添加/删除程序”中删除其所有条目。
- 干净、可逆的安装使用户能够部署和删除应用。 若要通过此测试,应用必须执行以下作:
- 测试详细信息
- 此测试检查应用的安装和卸载过程是否存在所需的行为。
- 纠正措施
- 根据上述要求查看应用的设计和行为。
安装到正确的文件夹测试
验证应用是否将其程序和数据文件写入正确的文件夹。
- 背景
- 应用必须正确使用用户系统和每用户文件夹,以便它可以访问所需的数据和设置,同时保护用户的数据和设置免受未经授权的访问。
- 程序文件文件夹
- 应用必须默认安装在 Program Files 文件夹中(本机 32 位和 64 位应用的%ProgramFiles%,对于在 x64 上运行的 32 位应用,%ProgramFiles(x86)%)。
- 注意: 由于为此文件夹配置的安全权限,应用不得将用户数据或应用数据存储在 Program Files 文件夹中。
- Windows 系统文件夹中的 ACL 仅允许管理员帐户读取和写入这些帐户。 因此,标准用户帐户将无权访问这些文件夹。 但是,文件虚拟化允许应用将文件(如配置文件)存储在通常只能由管理员写入的系统位置。 在这种情况下,以标准用户身份运行程序可能会导致失败,如果他们无法访问所需的文件。
- 应用应使用 已知文件夹 来确保它们能够访问其数据。
- 注意: Windows 提供文件虚拟化,以提高应用兼容性,并在 Windows 上以标准用户身份运行应用时消除问题。 你的应用不应依赖于未来版本的 Windows 中存在的虚拟化。
- 用户特定的应用数据文件夹
- 在“每台计算机”安装中,应用在安装过程中不得写入用户特定的数据。 仅当用户首次启动应用时,才应编写特定于用户的安装数据。 这是因为安装时没有正确的用户位置来存储数据。 安装后,应用尝试修改计算机级别的默认关联行为将失败。 相反,必须在每个用户级别声明默认值,从而阻止多个用户覆盖对方的默认值。
- 所有特定于特定用户的应用数据,而不是与计算机的其他用户共享都必须存储在 Users\<用户名>\AppData 中。
- 计算机上用户之间必须共享的所有应用数据都应存储在 ProgramData 中。
- 其他系统文件夹和注册表项
- 应用不应直接写入 Windows 目录或子目录。 使用这些目录安装文件(如字体或驱动程序)的正确方法。
- 应用不应在启动时自动启动,例如,将条目添加到以下一个或多个位置:
- 注册表运行密钥 HKLM,或在 Software\Microsoft\Windows\CurrentVersion 下运行 HKCU
- 注册表项 HKLM,或在 Software\Wow6432Node\Microsoft\windows\CurrentVersion 下运行 HKCU
- 启动菜单 AllPrograms > STARTUP
- 测试详细信息
- 此测试验证应用是否使用 Windows 提供的文件系统中的特定位置来存储程序和软件组件、共享的应用数据和特定于用户的应用数据。
- 纠正措施
- 查看应用如何使用系统的文件夹,并确保它正确使用它们。
- 例外和豁免
- 写入全局程序集缓存(GAC)(.NET 应用)的桌面应用需要豁免,除非明确需要共享程序集,否则应将其存储在应用的目录中。
- 安装到“程序文件”文件夹不需要桌面 SW 包才能实现 SW 徽标,而仅在 SW 基础知识类别下。
数字签名的文件测试
测试可执行文件和设备驱动程序,以验证它们是否具有有效的数字签名。
- 背景
- 经过数字签名的文件可以验证文件是否为正版,并检测文件是否已被篡改。
- 内核模式代码签名强制实施是一项 Windows 功能,也称为代码完整性(CI)。 CI 通过在每次将文件加载到内存中时验证文件的完整性来提高 Windows 的安全性。 CI 检测恶意代码是否已修改系统二进制文件,并在内核模块签名无法正确验证时生成诊断和系统审核日志事件。
- 如果应用需要提升的权限,提升提示会显示有关请求提升访问权限的可执行文件的上下文信息。 根据应用是否已签名验证码,用户可能会看到同意提示或凭据提示。
- 强名称可防止第三方欺骗代码,只要保持私钥的安全。 .NET Framework 在加载程序集或将其安装在 GAC 中时验证数字签名。 如果没有对私钥的访问权限,恶意用户将无法修改代码并再次对其进行签名。
- 测试详细信息
- 所有可执行文件(如文件扩展名为 .exe、.dll、.ocx、.sys、.cpl、.drv 和 .scr 的可执行文件)都必须使用 Authenticode 证书进行签名。
- 应用安装的所有内核模式驱动程序都必须具有通过 WHQL 或 DRS 程序获取的Microsoft签名。 所有文件系统筛选器驱动程序都必须经过 WHQL 签名。
- 纠正措施
- 对应用的可执行文件进行签名。
- 使用 makecert.exe 从某个商业证书颁发机构(CA)生成证书或获取代码签名密钥,例如 VeriSign、Thawte 或 Microsoft CA。
- 例外和豁免
- 豁免只被视为未签署的第三方可再发行组件。 请求可再发行组件(s)签名版本的通信证明需要授予此豁免。
- 设备增值软件包不受内核模式驱动程序认证,因为驱动程序必须通过 Windows 硬件认证进行认证。
支持 x64 Windows 测试
测试应用,确保为要安装到的平台体系结构构建 .exe。
- 背景
- 必须为安装可执行文件的处理器体系结构生成可执行文件。 某些可执行文件可能在不同的处理器体系结构上运行,但这并不可靠。
- 体系结构兼容性很重要,因为 32 位进程无法加载 64 位 DLL,64 位进程无法加载 32 位 DLL。 同样,64 位版本的 Windows 不支持运行基于 16 位 Windows 的应用程序,因为句柄在 64 位 Windows 上有 32 个有效位,因此无法将其传递给 16 位应用程序。 因此,尝试启动 16 位应用程序会在 64 位版本的 Windows 上失败。
- 32 位设备驱动程序无法在 64 位版本的 Windows 上运行,因此,它们必须移植到 64 位体系结构。
- 对于用户模式应用程序,64 位 Windows 包括 WOW64,它使 32 位 Windows 应用程序能够在运行 64 位 Windows 的系统上执行,尽管性能会丢失。 设备驱动程序不存在等效的转换层。
- 为了保持与 64 位版本的 Windows 的兼容性,应用必须以本机方式支持 64 位,或者至少,基于 Windows 的 32 位应用必须在 64 位系统上无缝运行:
- 应用及其安装程序不得包含任何 16 位代码或依赖于任何 16 位组件。
- 应用安装必须在 64 位版本的 Windows 上检测并安装正确的驱动程序和组件。
- 任何 shell 插件都必须在 64 位版本的 Windows 上运行。
- 在 WoW64 模拟器下运行的应用不应尝试绕过 Wow64 虚拟化机制。 如果在某些情况下,应用需要检测它们是否在 WoW64 模拟器中运行,则应通过调用 IsWow64Process来执行此作。
- 测试详细信息
- 应用不应安装任何 16 位二进制文件。 如果应用应在 64 位计算机上运行,则应用不应安装 32 位内核模式驱动程序。
- 纠正措施
- 为要为其安装它们的处理器体系结构生成可执行文件和驱动程序。
OS 版本检查测试
测试应用如何检查运行它的 Windows 版本。
- 背景
- 应用通过测试大于或等于所需版本的版本来检查 OS 版本,以确保与将来版本的 Windows 兼容。
- 测试详细信息
- 模拟在不同版本的 Windows 上运行应用,以查看应用的反应。
- 纠正措施
- 通过测试当前版本是否大于或等于应用、服务或驱动程序所需的版本来测试正确的 Windows 版本。
- 驱动程序安装程序和卸载模块绝不能检查 OS 版本。
- 例外和豁免
- 对于符合以下条件的应用,将考虑豁免:(仅适用于桌面应用认证)
- 作为在 Windows XP、Windows Vista 和 Windows 7 上运行的包交付的应用,需要检查 OS 版本以确定在给定作系统上安装哪些组件。
- 仅使用批准的 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“”/>
- 应用的主要进程必须以标准用户身份运行(asInvoker)。 任何管理功能都必须移动到使用管理权限运行的单独进程中。
- 需要提升权限的用户应用必须经过验证码签名。
- 测试详细信息
- 所有面向用户的 exe 都应标记为 AsInvoker 属性。 如果它们标记为 highestAvailable 或 requireAdministrator,则应正确对验证码进行签名。 任何应用 exe 都不应将 uiAccess 属性设置为 true。 作为服务运行的任何 exe 都从此特定检查中排除。
- 纠正措施
- 查看应用的清单文件,了解正确的条目和权限级别。
- 例外和豁免
- 对于使用提升的权限运行其主进程的应用(需要Administrator 或 highestAvailable),需要豁免。 主进程是向用户提供应用入口点的过程。
- 对于以下情况,将考虑豁免:
- 执行级别设置为 highestAvailable的管理或系统工具,需要administrator,或两者兼有。
- 只有辅助功能或 UI 自动化框架应用将 uiAccess 标志设置为 TRUE,以绕过用户界面特权隔离(UIPI)。 若要正确启动应用利用率,此标志必须经过验证码签名,并且必须驻留在文件系统中的受保护位置(如 Program Files)。
遵循系统重启管理器消息
测试应用如何响应系统关闭和重启消息。
- 背景
- 当应用收到通知时,应用必须尽快退出,系统正在关闭,以便为用户提供响应式关闭或关机体验。
- 在关键关闭中,将返回 FALSE 的应用发送到 WM_QUERYENDSESSIONWM_ENDSESSION 并关闭,而响应WM_QUERYENDSESSION超时的应用将强行终止。
- 测试详细信息
- 检查应用如何响应关闭和退出消息。
- 纠正措施
- 如果应用未通过此测试,请查看它如何处理这些 Windows 消息:
- WM_QUERYENDSESSIONLPARAM = ENDSESSION_CLOSEAPP(0x1):桌面应用必须立即响应(TRUE),才能准备重启。 控制台应用可以调用 SetConsoleCtrlHandler 来接收关闭通知。 服务可以调用 RegisterServiceCtrlHandlerEx 来接收处理程序例程中的关闭通知。
- WM_ENDSESSIONLPARAM = ENDSESSION_CLOSEAPP(0x1):应用必须在 30 秒内返回 0 值并关闭。 应用应至少通过保存任何用户数据来准备,并声明重启后所需的信息。
- 接收 CTRL_C_EVENT 通知的控制台应用应立即关闭。 驱动程序不得否决系统关闭事件。
- 注意: 由于无法中断的作而必须阻止关闭的应用应使用 ShutdownBlockReasonCreate 来注册解释用户原因的字符串。 作完成后,应用应调用 ShutdownBlockReasonDestroy 以指示系统可以关闭。
- 如果应用未通过此测试,请查看它如何处理这些 Windows 消息:
安全模式测试
测试驱动程序或服务是否已配置为以安全模式启动。
- 背景
- 安全模式允许用户诊断和排查 Windows 问题。 只有作系统的基本作所必需的驱动程序和服务或提供诊断和恢复服务才能以安全模式加载。 以安全模式加载其他文件可以更难解决作系统问题。
- 默认情况下,只有预安装 Windows 的驱动程序和服务以安全模式启动。 应禁用所有其他驱动程序和服务,除非系统要求它们执行基本作或出于诊断和恢复目的。
- 测试详细信息
- 应用安装的驱动程序不应标记为在安全模式下加载。
- 纠正措施
- 如果驱动程序或服务不应以安全模式启动,请从注册表项中删除应用的条目。
- 例外和豁免
- 必须以安全模式启动的驱动程序和服务需要豁免才能获得认证。 豁免请求必须包括每个驱动程序和服务,以添加到 SafeBoot 注册表项,并描述驱动程序或服务必须以安全模式运行的技术原因。 应用安装程序必须在以下注册表项中注册所有此类驱动程序和服务:
- HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
- HKLM/System/CurrentControlSet/Control/SafeBoot/Network
- 必须以安全模式启动的驱动程序和服务需要豁免才能获得认证。 豁免请求必须包括每个驱动程序和服务,以添加到 SafeBoot 注册表项,并描述驱动程序或服务必须以安全模式运行的技术原因。 应用安装程序必须在以下注册表项中注册所有此类驱动程序和服务:
- 注意: 必须测试要以安全模式启动的驱动程序和服务,以确保它们在安全模式下正常运行,且没有任何错误。
多用户会话测试
测试应用在多个会话中运行时的行为方式。
- 背景
- Windows 用户必须能够运行并发会话。 应用必须确保在多个会话中运行时(本地或远程)不会对应用的正常功能产生负面影响。 应用设置和数据文件必须特定于用户,并且用户的隐私和首选项必须限制为用户的会话。
- 测试详细信息
- 运行应用的多个并发实例以测试以下内容:
- 同时运行的应用的多个实例彼此隔离。
- 这意味着一个实例中的用户数据对另一个实例不可见。 活动用户会话中不应听到非活动用户会话中的声音。 如果多个应用实例使用共享资源,应用必须确保不存在冲突。
- 如果为多个用户安装了应用,它将数据存储在正确的文件夹和注册表位置。
- 应用可以在多个用户会话(快速用户切换)中运行,以便进行本地和远程访问。
- 若要确保这一点,应用必须检查应用现有实例的其他终端服务 (TS) 会话。 如果应用不支持多个用户会话或远程访问,则当从此类会话启动时,它必须清楚地向用户说这一点。
- 运行应用的多个并发实例以测试以下内容:
- 纠正措施
- 确保应用不会在用户特定的数据存储(如用户配置文件或 HKCU)中存储系统范围的数据文件或设置。 如果这样做,该信息将不适用于其他用户。
- 在安装过程中,应用必须安装系统范围的配置和数据文件,并在用户运行时创建用户特定的文件和设置。
- 确保应用不会在本地或远程阻止多个并发会话。 应用不得依赖于全局互斥体或其他命名对象来检查或阻止多个并发会话。
- 如果应用不允许每个用户多个并发会话,请对互斥体和其他命名对象使用每用户或每会话命名空间。
崩溃和挂起测试
在认证测试期间监视应用,以记录应用崩溃或挂起的时间。
- 背景
- 应用故障(如崩溃和挂起)对用户造成重大中断并造成挫折。 消除此类故障可提高应用稳定性和可靠性,整体而言,为用户提供更好的应用体验。 停止响应或崩溃的应用可能会导致用户丢失数据并体验不佳。
- 测试详细信息
- 在整个认证测试中,我们测试应用复原能力和稳定性。
- Windows 应用认证工具包调用 IApplicationActivationManager::ActivateApplication 来启动 Windows 应用商店应用。 若要 ActivateApplication 启动应用,必须启用用户帐户控制(UAC),并且屏幕分辨率必须至少为 1024 x 768 或 768 x 1024。 如果未满足任一条件,应用将无法通过此测试。
- 纠正措施
- 请确保在测试计算机上启用了 UAC。
- 请确保在具有足够大屏幕的计算机上运行测试。
- 如果应用无法启动,并且测试平台满足 ActivateApplication的先决条件,可以通过查看激活事件日志来解决问题。 若要在事件日志中查找这些条目,请执行以下作:
- 打开 eventvwr.exe 并导航到 \Windows Logs\Application 节点。
- 筛选视图以显示事件 ID:5900-6000。
- 查看日志条目以获取可能解释应用未启动的原因的信息。
- 排查问题的文件,确定并解决问题。 重新生成并重新测试应用。
- 其他资源
- 在软件开发生命周期中使用应用程序验证程序
- 应用程序验证程序
- 使用应用程序验证程序
- AppInit DLL
- 最小化启动时间(使用 C#/VB/C++ 和 XAML 的 Windows 应用商店应用)
兼容性和复原能力测试
- 背景
- 此检查将验证应用的两个方面,应用主可执行文件(例如,面向应用入口点的用户必须进行清单以保持兼容性),并声明正确的 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 安全保护可能会增加客户的风险。
- 测试详细信息
- 纠正措施
- 对测试标识的问题进行故障排除和修复。 重新生成并重新测试应用。
高 DPI 测试
强烈建议 Win32 应用识别 DPI。 使应用 UI 在各种高 DPI 显示设置中保持一致良好是关键。 在高 DPI 显示设置上运行的非 DPI 感知应用可能会遇到以下问题:UI 元素的缩放不正确、剪裁的文本和模糊图像。 声明应用的方法有两种感知 DPI。 一个是声明 DPI。
- 背景
- 此检查将验证应用的主要可执行文件(s)的两个方面,例如,必须显示面向应用入口点的用户,以便 HIGH-DPI 感知,并调用适当的 API 来支持 HIGH-DPI。 如果缺少其中一个或两个条件,应用将失败。 此检查将在桌面报表中引入新部分,请参阅以下示例。
- 测试详细信息
- 当我们检测到以下任一情况时,测试将生成警告:
- main EXE 在其清单中不声明 DPI 感知,也不会调用 SetProcessDPIAware API。 (如果他忘记添加 DPI 感知清单,请警告开发人员)。
- 主 EXE 在其清单中不声明 DPI 感知,但它调用 SetProcessDPIAware API(警告开发人员,他应使用清单声明 DPI 感知,而不是调用 API)。
- mainEXE 在其清单中声明 DPI 感知,但也调用 SetProcessDPIAware API(警告开发人员调用该 API 没有必要)。
- 对于不是主要 EXE 的二进制文件,如果他们调用 API,请发出警告(不建议调用 API)。
- 当我们检测到以下任一情况时,测试将生成警告:
- 纠正措施
- 不建议使用 SetProcessDPIAware() 函数。 如果 DLL 在其初始化过程中缓存 DPI 设置,则调用应用中的 SetProcessDPIAware() 可能会生成争用条件。 在 DLL 中调用 SetProcessDPIAware() 函数并不是一个好的做法。
- 其他信息