在听到术语“渗透测试”时，您可能会联想到一个孤独的天才正在对一些倒霉的软件执行神奇的测试。在渗透测试复兴之前，它或许是个真实的场景。现在，渗透测试的执行方式要系统化得多。这样做是必要的，因为安全开发生命周期 （SDL） 以及前载式安全设计和开发重点降低了潜在缺陷的数量，从而使在测试过程中查找漏洞的任务变得更加困难。软件安全测试非常重要，不能仅依靠一小组专家来完成。它必须是能够传授、系统化且可重复的过程，这样才能将其应用到各种情况中。

　　这并不是说渗透测试是一门科学。所有测试均有值行研究的方面；测试人员应用输入，而这些输入会更改软件内部的数据，从而导致其做出各种反应。由于复杂性很高，无法进行精确预测；但是，我们可事先做好各种规划工作，本专栏将介绍我们在 Microsoft 是如何制定规划的。

　　规划

　　对于传统测试而言，规范、用户文档、用例和其他设计文档非常充足。可使用这些信息设计一组测试用例来确认指定的功能。但有关规划的可用信息资源则非常有限。渗透测试并不是为了确认功能；其目的是确认不再存在不安全的功能。遗憾的是，没有人定义过用于此类行为的软件开发项目，因此测试人员不得不自行解决。

　　收集渗透测试信息的首个位置是软件与外部环境之间的接口。用户界面、网络接口、API 和处理输入的任意其他位置都是明显的黑客攻击目标。如果任意一个接口的设计或实现欠佳，它们可能会允许恶意伪造的输入并带来灾难。可通过确定和记录这些接口来开始执行渗透测试。

　　需要特别关注的第二个区域是错误消息和用户警告对话框（它们将把来自软件的信息传递给外部用户）。由于某些用户可能具有恶意企图，因此必须了解会向其显示哪些信息以及此类信息的传递方式。

　　最后，渗透测试人员通常会定义灾难场景，以此指出成功的攻击可能产生的后果。这些误用案例（或者说滥用案例）通常起源于某种威胁模型或先前已知的攻击。

　　对于渗透测试而言，从这三类资源中收集信息是至关重要的准备工作，并且有助于指导您完成实际的测试。

　　渗透测试类型

　　测试的对象是变化 — 找出软件及环境中可能发生变化的部分，改变它们，然后观察软件的反应。测试目标是确保软件在合理甚至不合理的生产环境中可靠且安全地运行。因此，测试人员可制定的最基本规划是了解哪些部分可能发生变化以及在测试中需使用哪些方法来分阶段实现这些变化。

　　从安全角度来看，环境、用户输入以及内部数据和逻辑是此类变化可能暴露出安全问题的主要位置。环境包括文件、应用程序、系统资源和应用程序使用的其他本地或网络资源。所有这些都可能成为攻击的入口点。用户输入是源自软件分析和使用的外部（通常不受信任）实体的数据。内部数据和逻辑是内部存储的变量和逻辑路径（它们具有多种可能的枚举）。

　　通过改变软件环境、输入域和数据/逻辑路径中的信息，就可以执行攻击。接下来我将更详细地介绍这三类攻击。

　　环境攻击

　　软件无法孤立地执行。它依赖于一些二进制和等效于代码的模块（如脚本和插件）。它还可能使用注册表或文件系统中的配置信息以及可能位于任意位置的数据库和服务。每个此类环境交互都可能成为安全漏洞的来源，因此必须对其进行测试。

　　对于应用程序在此类交互中所具有的信任程度，还有许多必须考虑的重要问题，其中包括：应用程序对于本地环境和远程资源的信任程度如何？应用程序是否将敏感信息放在其他应用程序可读取的资源（如注册表）中？它是否信任自身加载的每个文件或库，甚至无需确认内容？攻击者是否能够利用这种信任来强制应用程序服从其命令？