程序员十大安全技巧

　　如果在 .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 和线程上的模拟标记来进行一个访问检查。如果访问检查失败，本地文件系统会将其报告给文件系统重定向器，然后重定向器向远程客户端发送一个错误。毫无疑问，对文件系统重定向器来说这很方便，因为它只是简单地把请求传给本地文件系统，让它去做自己的访问检查，就好象客户端在本地一样。 这对于文件重定向器这样简单的网关而言，一切良好。但模拟常常用在其他更复杂的应用程序中。以一个 Web 应用程序为例。如果您编写一个经典的非托管 ASP 程序、ISAPI 扩展或 ASP.NET 应用程序，在它的 Web.config 文件中有如下指定

　　＜identity impersonate='true'＞

　　那么您的运行环境将有两种不同的安全环境：您将具有一个进程标记和一个线程标记，一般来说，线程标记会被用来做访问检查（见图 ）。假设您正在编写一个在 Web 服务器进程中运行的 ISAPI 应用程序，并假定大多数请求未经身份验证，则您的线程标记可能是 IUSR_MACHINE，而进程标记却是 SYSTEM！假设您的代码能被一个坏家伙通过缓冲区溢出利用。您认为他会只满足作为 IUSR_MACHINE 运行吗？当然不会。他的攻击代码很可能会调用 RevertToSelf 以删除模拟标记，从而希望提高他的权限级别。在这种情况下，他会很容易获得成功。他还可以调用 CreateProcess。它不会从模拟标记复制新进程的标记，而是从进程标记复制，这样新进程便可以作为 SYSTEM 运行。