关于安全测试的 10 个重要技巧.docx

关于安全测试的 10 个重要技巧

2 简介
本文提供关于使用安全的方式测试 Microsoft Windows 家族操作系统应用程序的信息。这些主题分为 10 个技巧，任何开发人员或测试人员都可以在测试应用程序或硬件设备驱动程序时应用它们。
要访问本文中提及的工具和资源，请参见本文末尾的“资源”。
返回页首
2 1. 不要以管理员身份运行测试。
开发人员和测试人员经常以本地管理员身份进行操作，因为这是最不会引起系统拒绝执行的方法。这种行为会给人一种虚假的稳定感觉，因为管理员实际上可以在系统上进行任何操作，所以大部分情况都很正常。一旦当前用户不是管理员，操作系统安全功能就开始生效了，这时事情就可能就不会那么顺利。幸运的是，有一个容易的解决方法：除非完全必要，不要以管理员身份运行任何测试。
使用 RUNAS 命令
Microsoft 为最近的 Windows 版本添加了一项出色的功能，允许当前登录的用户以不同的帐户运行另一个程序。从 Windows 资源管理器界面或从命令行使用 RUNAS 命令能够快速简单地指定非管理员帐户。
使用辅助本地计算机或域帐户
在本地计算机上创建一个只具有本地用户权限的用户。这样，运行测试的人员可以很快看到是否有功能由于为文件系统或网络访问假设了某种权限级别而无法工作。安装程序之后，在运行测试之前注销并以本地用户身份重新登录。
如果需要网络权限，那么请在测试系统上使用只具有用户特权的第二个域帐户。这样，网络权限就不会影响到测试，而管理员权限也不会引起虚假的安全感觉。
一些例外……
下面是一些例外，这些例外需要管理员访问权限可以接受：
•
设置和安装需要能够以一种稳固的方式更改系统状态。
•
维护和配置工具可能必需管理员权限。
在这些情况下，最好的编程实践是应用程序检查其启动时可用的权限，然后如果需要管理员权限才能使用所有功能，则对用户发出警告。
返回页首
2 2. 在安全的文件系统 (NTFS) 上进行测试
如果文件系统不安全，以管理员身份运行测试毫无益处。FAT12、FAT16 和 FAT32 只具有基本的文件权限，但是 NTFS 为测试所有类型的权限场景提供了完整而牢固的基础。
使用 NTFS
从一开始就使用 NTFS 系统驱动器安装所有测试机器。这样将会为操作系统配置基本的默认权限。在 Windows XP 和更高版本中，运行 CONVERT 命令会自动将安装默认权限应用于系统卷。
并且会考虑为用户打开磁盘配额。
首先在 NTFS 上测试，根据需要在其它文件系统上测试
因为 NTFS 是一个安全的文件系统，所以，如果测试的软件能在 NTFS 上正常运行，那么它也可能在使用其它不安全的文件系统时正常运行。在受限环境中运行良好的软件在不受限环境中通常也会运行良好。
注意文件系统之间的区别
除了文件系统权限之外，文件系统之间还有一些其它区别需要注意，例如最大文件、群集和分区大小。这些是测试边界情况的主要区域。
从受限环境开始，根据需要增加权限
如果当前用户无法访问特定的文件夹，软件还能够正常运行吗？特定文件操作需要的最小权限是什么？程序能否将文件保存到一个“下拉框”文件夹？
首先在文件夹或文件共享上使用受限的权限，然后在测试过程中逐步添加特权。
返回页首
2 3. 不要改变 HKLM 或 %PROGRAMFILES% 中的任何内容
非常多多的程序都假设可以不受限制地访问注册表的 HKEY_LOCAL_MACHINE 节和系统驱动器上的 %PROGRAMFILES% 文件夹。对于普通用户，这两项都是只读的。不要更改它们的任何内容，除了在安装的时候。
“徽标一致性”要求
针对应用程序徽标的 "Designed for Windows XP" 进行设计的应用程序不应该尝试写入 HKLM 或 %PROGRAMFILES%。请参见 "Designed for Windows XP" 应用程序规范的第 3.0 节。
以用户为基础存储数据
假设用户可以访问 %USERPROFILE% 文件夹，这是安全合理的。为临时数据文件使用 %TEMP% 文件夹。使用 %APPDATA% 来以每个用户为基础存储应用程序特定数据。考虑将数据存储在用户的“我的文档”文件夹下。对于注册表设置，请使用 HKEY_CURRENT_USER。
返回页首
2 4. 不要以明文形式存储或发送秘密信息
非常多的应用程序都使用简单的混淆来隐藏显而易见的信息。这可能防止了偶尔的窥探，但是它不能够提供任何有意义的保护。
使用 System.Security.Cryptography
Microsoft .NET 框架包含一个完整的类库，提供了用于哈希、加密、解密、签名等密码学函数。
不要存储秘密，而是存储哈希值
如果必须存储一些敏感内容而不需要解密，请不要存储秘密内容，而应该存储私密内容的单向哈希值。然后将计算出来的哈希值与秘密内容的哈希值相比较。
“加点盐”
计算或存储哈希值时，添加一个唯一的随机值（也就是一点“盐”），从而使相同数据的哈希值对于每个用户或机器都是唯一的。
了解信任边界
程序可以在哪些地方不再信任小心传输的数据？一个定义良好的信任边界非常必要。
法律因素
测试时应该考虑一些法律要求，例如 1996 年通过的健康保险流通与责任法案 (HIPAA)、计算机欺诈和滥用法案 (CFAA) 以及加利福尼亚 (CA) SB1386。
返回页首
2 5. 获取足够的功能文档
有时在开发周期的最后时刻才保存文档，但是文档是必需的，而且需要谨慎处理。请注意，这项提示的主题不是关于完美，而是项目组应该拥有关于每个特性的足够的文档。没有这类信息会加大将来诊断潜在的安全问题的难度。
了解 5 个 W
每项功能都需要记录 5 个方面，简称为：谁 (who)、什么 (what)、地点 (where)、时间 (when) 和原因 (why)。
列出文件
该功能使用哪些源文件？该功能产生了哪些临时文件？该功能允许用户打开或保存哪些数据文件类型？一定不要假设数据文件会在执行会话中保持不变。任何数据文件都可能在没有使用应用程序打开的情况下被恶意用户更改或操作。测试文件打开代码以进行健壮的错误处理。一定不要在代码中或测试期间假设一个特定的文件名以及类似内容（除非您完全确信文件名不会被恶意用户更改）。
列出注册表条目
该功能需要读取哪些注册表条目？注册表条目中存储了哪些数据格式？该功能需要将数据写到注册表中吗？
列出数据格式和类型
该功能以 XML 或其它格式存储或传输数据吗？使用什么方案？方案（或相关格式）中字段的有效范围是什么？程序是否以专用的二进制格式存储数据？如果数据被更改会发生什么情况？
列出错误消息
该功能是否会在某些情景下失败？错误消息提供的信息是否太多？例如，最好提示用户名和密码的某种组合错误（而不指定究竟是用户名错误还是密码错误），而不是告诉用户密码错误。
返回页首
2 6. 限制恶意数据
使用提示 5 的文档，分析每个数据字段的边界条件，然后设计测试来检查每个字段的有效性。
检查所有数值范围
字段是数值的吗？字段是整数吗？允许负数吗？最大值是多少？最小值是多少？
检查所有缓冲区大小
如果字段大小是 255 个字符，那么当输入字符串是 256 个字符时会发生什么？当输入字符串是 256 个 Unicode 字符时会发生什么？
用户数据只有在经过证实后才可以信任
软件能够接受用户的输入吗？程序从 Internet 上下载文件吗？数据经过彻底的范围检查了吗？如果接收到恶意数据流会发生什么？所有输入都必须在使用之前经过适当和完全的验证。软件一定不要假设用户数据文件在执行过程中没有发生更改。
更改日期格式
如果该功能期望美国格式的日期（例如 10/13/2003），那么当日期是欧洲格式 (13/10/2003) 时会发生什么？不要忘记测试不可能的日期（例如 02/29/2013）。
更改数字格式
如果该功能期望美国格式的数字（例如 3.14159），那么当输入欧洲格式 (3,1415926) 时会发生什么？
注入脚本
如果该功能接受来自 web 页表单的输入，那么能不能将脚本函数插入文本字段中执行？检查 web 页源代码以查看是否不小心留下了任何敏感的详细信息，例如 SQL 数据库服务器密码、开发注释等。
返回页首
2 7. 在两个或多个处理器上进行测试
随着诸如 Intel Pentium 4 处理器中的超线程等技术的出现，对称多处理 (SMP) 如今正变得越来越常见。越来越多的客户希望使用具有 SMP 功能的系统。每个驱动程序都应该在支持 SMP 的系统上进行测试。每个多线程应用程序都应该在多 CPU 系统上进行测试，从而确保一个或多个线程能够在同一时刻正常执行。类似的，每个硬件驱动程序都应该在 SMP 系统上进行测试。应该特别关注多用户软件，因为在一个用户的进程空间中执行的线程不应该允许另一个用户的违法访问。还应该在 64 位平台上测试驱动程序，对于 64 位系统，要特别关注 PAE 等问题。
每个测试人员和开发人员都应该具备的条件
请确保软件项目的每个测试人员和开发人员都至少拥有一台能够使用的支持 SMP 的系统。
打开超线程
如果测试系统在 Pentium 4 超线程 CPU 上运行 Windows XP 或 Windows Server 2003，那么要进行 SMP 测试，只需确保在 BIOS 设置中启用超线程。
添加第二个处理器
许多工作站级别的计算机都可以通过添加处理器来支持 SMP。启用 SMP 的一种快速、廉价（与购买新计算机相比）而简便的方法是购买并安装第二个处理器。
关于早期 Windows 发布版的警告
Windows 2000 和早期 Windows 操作系统不支持在单个和多个 CPU 之间进行动态切换。将第二个处理器添加到早期的系统可能需要重新安装操作系统。在所有可接受的系统上测试整个包，并用文档记录需要安装哪些服务包。
返回页首
2 8. 了解 20 条安全准则
每个软件开发人员都应该熟悉文章“10 条永恒的安全准则”和“10 条永恒的安全管理准则”（例如通过测试来确保失败的安装或使用不会将系统置于不安全状态）。这些规则和Writing Secure Code（第二版）中的大量信息为理解什么是设计良好和安全的软件提供了一个良好的起点。
深入实践防御
仅仅存在一个可能的安全漏洞并不意味着游戏结束。如果特定的安全技术失败，那么应该定义一些方法来降低直接风险和次要风险。定义、设计并构建了降低风险的方法之后，对其进行测试。请记住，设计良好的软件会正常地失败并跳转到安全模式。如果有所怀疑，则拒绝访问。虽然允许安装权限获得管理权限，但它不应该将系统置于不安全的状态。确保安装程序未配置超出软件运行所需的最低特权的任何内容。
将安全性设计到产品中
开始开发时就考虑安全性，不要尝试在以后加入安全功能。创建一个威胁模型，并作为设计过程的一个重要部分。在编写代码之前分析潜在的威胁可以减少以后在减轻安全威胁方面的工作。仔细的设计可以减小暴露给潜在的恶意用户的“表面区域”。
保护所有测试系统
在不安全的系统上测试安全性毫无价值！适当地使用补丁包、防病毒软件和防火墙来保护所有测试系统。这对于要 Internet 进行通信的程序尤其重要。
返回页首
2 9. 使用可用的工具
Microsoft 和其它独立软件供应商拥有一些廉价的工具可用来进行加强、更新、扫描、测试和评估软件安全性。
Windows Update
Windows 2000 Service Pack（SP）3、Windows XP 和 Windows Server 2003 中内置的 Windows Update 和自动更新功能是测试系统通过获取所有最新的补丁包来保持最新的最佳方法。定期更新所有测试系统。
Microsoft Baseline Security Analyzer，v. 1.2
Microsoft Baseline Security Analyzer (MBSA) 是一个免费的工具，用于扫描和评估任何系统（客户端和服务器）与安全最佳实践的一致性。MBSA 检查补丁状态以及各种其它系统设置，然后提供一个关于如何更正所发现的问题的简单报告。
Microsoft Windows Application Compatibility Toolkit，v. 3.0
Windows Application Compatibility Toolkit，v3.0 包含几个有用的工具，可以用来检测前面提示中提到的许多问题。Application Verifier 对于检测常见的软件问题特别有用。这个工具包可以免费使用。
网络扫描工具
Network Monitor (NetMon) 和其它网络扫描和分析工具对于在进行特定的软件测试期间查看和分析计算机之间的网络流量非常有用。仔细分析数据可以发现哪些地方还存在未被完全降低的风险。
返回页首
2 10. 分析源代码
仔细检查源代码的安全性可以揭示潜在的安全漏洞和风险。Writing Secure Code（第二版）对于检查哪些方面有一些优秀的建议。
进行代码检查
将与特定功能相关的所有部分集中起来并逐行检查它们的代码。在以多人同意的方式下对发现的任何问题进行更改之后，都应该进行验证。
查找存在风险的函数
Writing Secure Code（第二版） 包含一系列优秀的附录，其中列出了经常被错误使用的函数及其引起的潜在安全漏洞。考虑将对不安全的函数的所有引用替换为建议的备选函数。
使用自动化扫描
使用自动化的源代码分析工具（例如为驱动程序使用 PREfast）可以加快代码检查过程并提供一致的反馈。虽然一些工具偶尔会给出错误的反馈，但是仍然应该仔细检查任何反馈。