Windows 应用程序开发安全性最低限度检查清单

下载 Excel 版检查清单

一说到 Windows 应用程序的安全性,话题很容易一下子变得很大。

零信任、EDR、SBOM、证书运维、漏洞管理。这些都很重要,但在实际工作中,在这之前还有不少不想遗漏的基本要点。

尤其是以下这类应用程序,与”高级防御”相比,先堵住基本漏洞更有效果。

• WPF / WinForms / WinUI 桌面应用程序
• C++ / C# 编写的 Win32 应用程序
• 设备联动、文件联动、数据库连接、内部分发工具
• 具有自动更新机制的业务应用程序
• 包含 Windows 服务或辅助 EXE 的构成

在 Windows 应用程序开发中,与一次性把所有事情都做到完美相比,先不留下明显危险的漏洞更现实。 本文按设计、实现、分发、运维的顺序,以便于检查的形式整理出最低限度不想遗漏的要点。

1. 先说结论

• 最先不想遗漏的是:不要求不必要的管理员权限、进行签名、不以明文保存机密信息、不停用证书验证。
• 对于 Windows 应用程序来说,分发物本身就是攻击面。把 EXE / DLL / MSI / MSIX / 自动更新模块也纳入视野会更安全。
• ServerCertificateValidationCallback => true、明文连接字符串、LoadLibrary("foo.dll") 式的粗糙加载,以及用字符串拼接执行 SQL,这些即便是最低限度也应该避免。
• 如果只有部分处理需要管理员权限,不要把整个应用程序提升权限,而是把那部分单独分离到别的 EXE 或服务中,这样更安全。
• 在 Windows 上分发的应用程序,最好以签名 + 时间戳为前提来考虑。这样不仅能提升用户的信任度,也更容易做篡改检测和运维说明。
• 保存时的机密信息应根据用途分别使用 DPAPI / ProtectedData 或 Credential Locker。至少应该摆脱把机密信息以明文放在 appsettings.json 中的状态。
• 日志并不是越多越好。如果token、密码、连接字符串、个人信息、完整的请求正文被原样保留,日志本身就会变成事故的主角。

最低限度的安全性,与其说是要增加特殊功能,不如说是不要留下危险的默认行为或粗糙的实现。

2. 本文的对象范围以及”最低限度”的含义

2.1. 涉及的范围

本文设想的是以下这类 Windows 应用程序。

• WPF / WinForms / WinUI 桌面应用程序
• C++ / C# 编写的 Win32 应用程序
• 内部分发工具、设备联动工具、监控工具
• 包含辅助 EXE、Windows 服务、更新程序的构成
• 以 EXE / MSI / MSIX 形式分发的业务软件

这里所说的”最低限度”,不是能通过审计的最终形态,而是指一旦缺失就很容易出事故的项目。

2.2. 不涉及的范围

另一方面,本文也会把一些内容排除在讨论核心之外。

• 企业整体的零信任设计
• EDR / SIEM / DLP / MDM 的整体运维
• 内核驱动的详细加固
• 从零开始进行加密设计本身
• 高级威胁分析或数字取证流程

也就是说,本文要处理的不是”组织整体的庞大安全举措”,而是Windows 应用程序开发者在发布前凭自身力量很难遗漏的基本底线。

3. 先看检查清单

在展开细节讨论之前,先放一张能纵览全局的表格。 光看这张表,就能大致把握需要重新审视的地方。

3.1. 总体概览

3.2. 权限以 asInvoker 为基本

在 Windows 应用程序中,最先想重新审视的就是这一点。 如果整个应用程序以管理员权限运行,那么 bug、DLL 被替换、配置文件误读、外部输入的缺陷,都会直接以强权限执行。

基本方针如下。

• 普通 UI 应用程序以 asInvoker 运行
• 只把需要管理员权限的处理分离到单独的进程或服务中
• 只在必要的瞬间才提升权限
• 传给辅助 EXE 或服务的输入也要进行验证

如果通常只是查看和编辑功能的桌面应用程序,只有安装或更改防火墙设置需要管理员权限,那么与把整个应用程序设为 requireAdministrator 相比,只把需要提升权限的部分交给 broker 处理会更安全。

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" uiAccess="false" />
    </requestedPrivileges>
  </security>
</trustInfo>

“以管理员身份运行更省事”这种想法,大多会在后面反噬自己。 以最小权限运行,再把真正需要的操作单独切出来,事故的波及范围会大大缩小。

3.3. 对二进制文件和安装程序进行签名

在 Windows 上,分发物的可信度至关重要。 用户接触到的不是源代码,而是 EXE、DLL、MSI、MSIX、更新程序。如果这些没有签名,运维上的说明、篡改检测、分发时的安心感都会变弱。

最低限度应关注以下几点。

• 对 EXE / DLL / MSI / MSIX 进行签名
• 不仅是安装程序,更新时使用的辅助二进制文件也要签名
• 附加时间戳
• 把证书的有效期和更新流程纳入发布流程

尤其是没有附加时间戳的签名,在证书过期后的验证中很容易出问题。 与”签了名就完事”相比,把签名 + 时间戳纳入发布流程会更稳妥。

如果使用 MSIX,包签名是前提条件。 即便采用 MSI / EXE 分发,至少也应该对安装程序本身和主要的可执行二进制文件进行签名。

3.4. 固定更新路径,加入篡改检测

如今的 Windows 应用程序,更新路径往往比首次安装被使用得更久。 如果这里做得粗糙,即便本体做得再精细,更新程序也会成为最薄弱的一环。

关于更新,最低限度需要考虑以下 5 点。

• 更新文件的获取以 HTTPS 为前提
• 对下载到的更新物进行签名或哈希验证
• 不让更新来源 URL 能被代码或配置无限制地替换
• 更新模块本身也要签名
• 确定回滚方案或失败时的恢复流程

如果能采用 MSIX + App Installer,就更容易把更新机制交给系统层面处理。 另一方面,如果使用自研更新程序,则需要同时确认通信的安全性和分发物的真实性这两点。仅靠 HTTPS 能保护”通信路径”,却无法保证”这个文件确实是自己发布的”。

3.5. 不把机密信息放在源代码或明文配置中

这里在实际工作中真的很容易出事故。 由于”因为是内部工具”、”反正只是分发 exe 而已”这类想法,连接字符串、API 密钥、共享文件夹凭据、固定 token 很容易被放进源代码或配置文件。

以下这类做法,最低限度也应该避免。

• 直接写在源代码中的 API 密钥
• appsettings.json 或 app.config 中的明文密码
• 进入版本库的连接字符串
• 把解密密钥和密文放在同一处的设计
• 不是按用户区分、而是全体共用的固定凭据

在 Windows 应用程序中,现实可行的选项大致有以下 4 种。

• 想保存 Windows 凭据 packaged desktop app / WinUI 系列可考虑使用 Credential Locker
• 想在本地加密保存机密信息 Win32 / .NET 可使用 DPAPI / ProtectedData
• 连接目标可以使用 Windows 身份验证或集成身份验证 尽可能不让应用程序持有密码
• 可以在云端或服务器端管理机密信息 优先考虑不在客户端嵌入长期机密的设计

对 C# 而言,哪怕只是像下面这样使用 DPAPI,也比明文保存好得多。

using System.Security.Cryptography;
using System.Text;

byte[] plaintext = Encoding.UTF8.GetBytes(secretText);
byte[] ciphertext = ProtectedData.Protect(
    plaintext,
    optionalEntropy: null,
    scope: DataProtectionScope.CurrentUser);

这里重要的不是”加密了就安全”,而是通过设计决定谁能解密。 设为 CurrentUser 还是 LocalMachine,含义会有相当大的不同。

对于 SQL Server 连接,在本地环境中有时可以把 Windows 身份验证作为首选。 如果无论如何都要在连接字符串中包含凭据,至少应保持 Persist Security Info=False,不要一直把它放在明文配置文件里。

3.6. 通信以 HTTPS 为前提,不要扼杀证书验证

只是开发期间临时加入的漏洞,却原样留在了正式环境。 通信方面的事故,大多是这种模式。

尤其容易残留在出货物中的,是这类代码或设置。

• ServicePointManager.ServerCertificateValidationCallback += ... => true
• HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
• 出货时仍停用证书吊销确认
• 把以开发用自签名证书为前提的代码留在正式环境中

最低限度的方针很简单。

• 正式环境通信使用 HTTPS
• 不要始终跳过证书验证
• 如果确实需要例外放宽验证,也要限定目标主机和证书
• 通过构建条件或配置,确保排除开发用的绕过代码
• 在 .NET 中也要意识到吊销确认

不好的例子大致是这样。

ServicePointManager.ServerCertificateValidationCallback +=
    (_, _, _, _) => true;

看起来很省事,但这几乎等同于”这个 HTTPS 通信连到任何对象都会放行”。 去掉证书验证之后,即便用了 HTTPS,内容也会被相当程度地掏空。

3.7. 把所有外部输入都当作”不可信输入”处理

Windows 应用程序不是 Web 应用程序,所以输入验证很容易变得松懈。 但实际上,外部输入的入口比想象中要多得多。

• 文件路径
• CSV / Excel / JSON / XML
• 命令行参数
• named pipe / socket / COM / RPC / gRPC
• 传给数据库的字符串
• 注册表值
• 剪贴板
• URL / deep link
• 来自外部设备或 SDK 的返回数据

尤其最低限度不想遗漏的是以下 3 点。

1. SQL 必须参数化 不要用字符串拼接来组装 SQL。
2. 文件路径要先规范化再使用 不要把用户指定的路径原样用于删除、覆盖、解压。
3. 读取外部文件时要加入大小上限和格式检查 “能打开”不代表”安全”。

以 SQL 为例,这种写法应该避免。

var sql = "SELECT * FROM Users WHERE Name = '" + userName + "'";

至少应该改成这样。

using System.Data;
using Microsoft.Data.SqlClient;

using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT * FROM Users WHERE Name = @name";
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 256).Value = userName;

“因为是内部工具,所以输入可信”是相当危险的前提。 现实中,损坏的 CSV、意外的文件名、过时的数据库数据、运维人员的手工输入失误、其他工具写出的不完整 JSON,都会大量出现。

3.8. 不要让 DLL 的加载来源变得含糊

这是很有 Windows 特色的陷阱。 如果像 LoadLibrary("foo.dll") 那样仅凭名称加载 DLL,根据搜索顺序的不同,有可能加载到意料之外位置的 DLL。

要做的事情是明确的。

• 尽可能指定 DLL 的绝对路径
• 在早期阶段设置 SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS)
• 用 AddDllDirectory 显式添加要搜索的目录
• 避免把 SearchPath 的结果直接传给 LoadLibrary 的设计
• 不要完全依赖 safe DLL search mode

例如对于原生代码,在进程初始化的早期阶段加入以下代码是一种有效的做法。

SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS);

然后,只通过 AddDllDirectory 注册确实需要的额外目录。

这里因为”平时能正常运行”而容易被放着不管,但一旦分发环境的工作目录发生变化,或者其他产品的 DLL 混进了 PATH,就会悄无声息地崩掉。 这不仅关乎安全性,对故障预防也相当有效。

3.9. 不在日志和异常中暴露机密信息

为了排查故障而增加日志是很重要的。 但日志同样很容易变成机密信息的坟场。

关于日志,最低限度应重新审视以下几点。

• 不在日志中输出密码、Bearer token、API 密钥
• 不要原样输出整个连接字符串
• 对个人信息或业务数据正文进行遮蔽
• 把异常详情在面向用户的界面和内部日志之间分开处理
• 不在正式环境中启用调试用的 PII 日志
• 重新审视 dump 或 trace 保存位置的访问权限

在最近的 .NET 中,以 redaction 为前提进行整理也变得更容易了。 至少应该摆脱”什么都直接字符串化然后写日志”的做法。

举几个常见的失误。

• 把 HTTP 请求 / 响应正文整个保存下来
• 身份验证失败时输出 token 或整个请求头
• 把异常信息原样显示在 MessageBox 中
• 在维护用的 ZIP 包中一并打包全部机密日志

错误提示可以像下面这样分开处理。

• 面向用户:”连接服务器失败。请检查网络设置和 URL。”
• 内部日志:失败的目标主机、TLS 错误类型、关联 ID、堆栈跟踪、重试次数

仅靠这样的区分,信息泄露与可排查性之间的平衡就能得到相当大的改善。

3.10. 不要放任依赖库和开发工具不管

最后一点虽然不起眼,但效果很大。 即便把应用程序本体做得很精细,如果继续搭载旧版运行时或存在已知漏洞的依赖库,根基还是会出问题。

需要关注的项目本身并不多。

• 让 .NET SDK / runtime 保持在受支持的版本
• 定期确认 NuGet / 开源依赖的更新情况
• 如果是 C++,要管理运行时再分发组件和外部 DLL 的版本
• 把漏洞信息的确认纳入发布前检查
• 准备好 smoke test,以免依赖更新导致功能损坏

“以后再统一处理”在这里是最危险的想法。 放置半年、一年之后,更新的差异会变得过大,安全应对本身就会变成一项繁重的工作。

4. 发布前检查清单

作为可以直接用于评审或出货判定的模板,将其整理成便于使用的形式。 为便于用表格确认,按类别列出发布前最低限度想检查的项目。

4.1. 权限、执行方式

4.2. 分发、签名

4.3. 更新

4.4. 机密信息

4.5. 通信

4.6. 输入、数据访问

4.7. DLL 与运行环境

4.8. 日志、运维

5. 常见的错误认识

在实际工作中经常见到的,大多是这类固有观念。

5.1. “因为是内部工具所以没问题”

即便是内部工具,损坏的文件、误操作、外来终端、共享文件夹、旧版 DLL、粗糙的权限设置也都很常见。 即便没有对外发布到互联网,攻击面也不会因此消失。

5.2. “因为是 HTTPS 所以安全”

HTTPS 固然重要,但一旦停用证书验证,其意义就会大打折扣。 另外,在更新分发中,除了 HTTPS 之外,还需要验证分发物的真实性。

5.3. “加密了所以安全”

如果没有整理好解密密钥的存放位置、解密权限、用户边界、机器边界,仅靠加密是不够的。 尤其是把用 LocalMachine 保护的值当作”按用户区分的机密”来使用,后面会造成混乱。

5.4. “增加日志就能排查问题”

如果日志只是数量多,而 token 或个人信息却被大量泄露,这本身就会成为一次事故。 如果想要可排查性,应该先决定保留什么、隐藏什么。

5.5. “以管理员身份运行就能解决”

一开始很省事,但之后在 UAC、分发、支持、权限边界、DLL 加载、文件保存位置等方面大多会变得棘手。 从长期来看,最小权限更稳定。

6. 大致的优先顺序

如果一次性做完所有事情负担太重,优先顺序大致如下。

1. 重新审视管理员权限 首先停止常态化使用 requireAdministrator。
2. 签名与时间戳 整理好分发物的可信度。
3. 转移机密信息 把机密信息从源代码、明文配置中移除。
4. 修正 HTTPS + 证书验证 从出货物中去除 => true 之类的代码。
5. 重新审视 SQL / 文件 / IPC 输入 减少字符串拼接和无验证输入。
6. 固定 DLL 加载 停止仅凭名称加载、依赖 PATH 的做法。
7. 对日志进行遮蔽 避免日志在事故发生时成为二次灾害。
8. 常态化依赖更新 建立每次发布都确认一次的流程。

按这个顺序推进,就能理解为”先堵住明显危险的漏洞”这一含义,也更容易推进。

7. 总结

Windows 应用程序开发的安全性,在引入特殊产品或庞大机制之前, 只要整理好权限、签名、机密信息、通信、输入、DLL、日志这 7 点,就会有相当大的改观。

如果用一句话概括最低限度的底线,大致是这样。

• 不让整个应用程序以管理员权限运行
• 对分发物和更新物进行签名,并附加时间戳
• 不把机密信息放在源代码或明文配置中
• 即使使用 HTTPS,也不扼杀证书验证
• 不信任 SQL、文件、IPC 等外部输入
• 不让 DLL 的加载来源变得含糊
• 不在日志中暴露机密信息
• 不放任依赖库不管

安全性的话题很宽泛,但并不需要从一开始就做到面面俱到。 不过,不把危险的默认行为原样出货这一最低限度,值得在相当早的阶段就一并落实。

8. 参考资料

• Administrator Broker Model - Win32 apps
• How User Account Control works
• Authenticode Digital Signatures
• Time Stamping Authenticode Signatures
• Sign a Windows app package
• Credential Locker for Windows apps
• CryptProtectData function (dpapi.h)
• CA5359: Do not disable certificate validation
• CA5399: Enable HttpClient certificate revocation list check
• Configuring parameters - ADO.NET Provider for SQL Server
• Connection String Syntax - ADO.NET
• Dynamic-Link Library Security - Win32 apps
• SetDefaultDllDirectories function (libloaderapi.h)
• Data redaction in .NET

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

Windows 应用程序安全性方面首先应该关注什么？

有四点：不要求不必要的管理员权限、进行代码签名、不以明文保存机密信息、不停用证书验证。最低限度的安全性,与其说是要增加特殊功能,不如说是不要留下危险的默认行为或粗糙的实现。始终跳过证书验证、明文连接字符串、依赖当前目录的 DLL 加载、用字符串拼接执行 SQL,这些即便是最低限度也应该避免。

整个应用程序都以管理员权限运行不行吗？

应该避免这样做。如果整个应用程序以管理员权限运行,那么 bug、DLL 被替换、配置文件误读、外部输入的缺陷,都会直接以强权限执行。基本方针是让普通 UI 应用程序以 asInvoker 运行,只把需要管理员权限的处理分离到单独的进程或服务中,只在必要的瞬间才提升权限。

API 密钥或连接字符串应该保存在哪里？

首先应该摆脱把它们以明文放在源代码或 appsettings.json 等配置文件中的状态。保存时的机密信息,应根据用途分别使用 DPAPI / ProtectedData 或 Credential Locker。另外,如果日志中原样保留 token、密码、连接字符串、个人信息,日志本身就会变成事故的主角,因此需要进行遮蔽处理。

即使是内部分发的应用程序,也需要代码签名吗？

最好当作前提来看待。在 Windows 应用程序中,分发物本身(EXE / DLL / MSI / MSIX / 自动更新模块)就是攻击面。有了代码签名 + 时间戳,就能获得篡改检测、对用户的可信度,以及在运维上更易于说明等好处。更新机制也应固定更新来源,并通过 HTTPS 与签名校验来实现可检测篡改的形式。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。