当您设计、建立并部署服务器应用程序时，您不能假设所有请求都来自合法用户。如果一个坏家伙发送给您一个恶意请求（但愿不会如此）并使您的代码产生恶劣操作，您会希望您的应用程序拥有所有可能的防护来限制损害。因此我们认为，您的公司实施安全策略不仅是因为它不信任您或您的代码，同时也是为了保护不受外界有企图的代码的伤害。

最小授权原则认为，要在最少的时间内授予代码所需的最低权限。也就是说，任何时候都应在您的代码周围竖起尽可能多的防护墙。当发生某些不好的事情时 - 就象 Murphy 定律保证的那样 - 您会很高兴这些防护墙都处在合适的位置上。因此，这里就使用最小授权原则运行代码给出了一些具体方法。

为您的服务器代码选择一个安全环境，仅允许其访问完成其工作所必需的资源。如果您代码中的某些部分要求很高的权限，请考虑将这部分代码分离出来并单独以较高的权限运行。为安全分离这一以不同的操作系统验证信息运行的代码，您最好在一个单独的进程（运行在具有更高权限的安全环境中）中运行此代码。这意味着您将需要进程间通讯（如 COM 或 Microsoft .NET 远程处理），并且需要设计该代码的接口以使往返行程最小。

如果在 .NET Framework 环境中将代码分离成程序集，请考虑每段代码所需的权限级别。您会发现这是一个很容易的过程：把需要较高权限的代码分离到可赋予其更多权限的单独的程序集中，同时使其余大部分程序集以较低的权限运行，从而在您的代码周围添加更多的防护。 在进行此操作时，不要忘了，由于代码访问安全 (CAS) 堆栈的作用，您限制的不仅是自己程序集的权限，也包括您调用的任何程序集的权限。

许多人建立了自己的应用程序，使得其产品在测试并提供给客户后可以插入新的组件。保护这种类型的应用程序非常困难，因为您无法测试所有可能的代码路径来发现错误和安全漏洞。然而，如果您的应用程序是托管的，则 CLR 提供了一个极好的功能，可以使用它关闭这些可扩展点。通过声明一个权限对象或一个权限集并调用 PermitOnly 或 Deny，您可以为自己的堆栈添加一个标记，它将阻塞授予您调用的任何代码的权限。通过在调用某个插件之前进行此操作，您就可以限制该插件所能执行的任务。例如，一个用于计算分期付款的插件不需要任何访问文件系统的权限。这只是最小权限的另一个例子，由此您可以事先保护自己。请确保记录下这些限制，并注意，具有较高权限的插件能够使用 Assert 语句逃避这些限制。

8. 注意失败模式

接受它吧。其他人和您一样憎恨编写错误处理代码。导致代码失败的原因如此众多，一想到这些就让人沮丧。大多数程序员，包括我们，更愿意关注正常的执行路径。那里才是真正完成工作的地方。让我们尽可能快而无痛地完成这些错误处理，然后继续下一行真正的代码吧。

只可惜，这种情绪并不安全。相反，我们需要更密切地关注代码中的失败模式。人们对这些代码的编写通常很少深入注意，并且常常没有经过完全测试。还记得最后一次您完全肯定调试过函数的每一行代码，包括其中每一个很小的错误处理程序是什么时候？

未经测试的代码常会导致安全漏洞。有三件事情可以帮助您减轻这个问题。首先，对那些很小的错误处理程序给予和正常代码同样的关注。考虑当您的错误处理代码执行时系统的状态。系统是否处于有效并且安全的状态中？其次，一旦您编写了一个函数，请逐步将它彻底调试几遍，确保测试每一个错误处理程序。注意，即使使用这样的技术，也可能无法发现非常隐秘的计时错误。您可能需要给您的函数传递错误参数，或者以某种方式调整系统的状态，以使您的错误处理程序得以执行。通过花时间单步调试代码，您可以慢下来并有足够的时间来查看代码以及系统运行时的状态。通过在调试器中仔细单步执行代码，我们在自己的编程逻辑中发现了许多缺陷。这是一个已得到证明的技术。请使用这一技术。最后，确保您的测试组合能使您的函数进行失败测试。尽量使测试组合能够检验函数中的每一行代码。这能帮助您发现规律，特别是当使测试自动化并在每次建立代码后运行测试时。

关于失败模式还有一件非常重要的事情需要说明。当您的代码失败时要确保系统处于可能的最安全状态。下面显示了一些有问题的代码：

bool accessGranted = true; // 过于乐观！
try {
// 看看我们能否访问 c:\test.txt
new FileStream(@"c:\test.txt",
FileMode.Open,
FileAccess.Read).Close();
}
catch (SecurityException x) {
// 访问被拒绝
accessGranted = false;
}
catch (...) {
// 发生了其他事情
}

尽管我们使用了 CLR，我们仍被允许访问该文件。在这种情况下，并没有引发一个 SecurityException。但是，例如，如果文件的自由访问控制列表 (DACL) 不允许我们访问呢？这时，会引发另一种类型的异常。但由于代码第一行的乐观假设，我们永远也不会知道这一点。
编写这段代码的一种更好的方法就是持谨慎态度：

bool accessGranted = false; // 保持谨慎！
try {
// 看看我们能否访问 c:\test.txt
new FileStream(@"c:\test.txt",
FileMode.Open,
FileAccess.Read).Close();
// 如果我们还在这里，那么很好！
accessGranted = true;
}
catch (...) {}

这样会更加稳定，因为无论我们如何失败，总会回到最安全的模式。
9. 模拟方式非常容易受到攻击

编写服务器应用程序时，您常常会发现自己直接或间接使用了 Windows 的一个称为模拟的很方便的功能。模拟允许进程中的每个线程运行在不同的安全环境中，通常是客户端的安全环境。例如，当文件系统重定向器通过网络收到一个文件请求时，它对远程客户端进行身份验证，检查以确认客户端的请求没有违反共享上的 DACL，然后把客户端的标记附加到处理请求的线程上，从而模拟客户端。然后此线程便可以使用客户端的安全环境访问服务器上的本地文件系统。由于本地文件系统已经是安全的，因此这样做很方便。它会考虑所请求的访问类型、文件上的 DACL 和线程上的模拟标记来进行一个访问检查。如果访问检查失败，本地文件系统会将其报告给文件系统重定向器，然后重定向器向远程客户端发送一个错误。毫无疑问，对文件系统重定向器来说这很方便，因为它只是简单地把请求传给本地文件系统，让它去做自己的访问检查，就好象客户端在本地一样。