程序员的“十大安全技巧”
程序员的“十大安全技巧”
06-07 19:30:49 浏览次数:273次 栏目：电脑安全
标签：电脑安全防护,电脑安全设置,
程序员的“十大安全技巧”,http://www.nx899.com
[1] [2] [3] [4] [5]
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 运行。
那么怎样解决这个小问题呢？除了首先确保不出现任何缓冲区溢出外，还要记住最小授权原则。如果您的代码不需要具有 SYSTEM 这样大的权限，则不要将 Web 应用程序配置为在 Web 服务器进程中运行。如果只是将 Web 应用程序配置为在中等或较高的隔离环境中运行，您的进程标记将会是 IWAM_MACHINE。您实际上没有任何权限，因而这种攻击几乎不会生效。注意，在 IIS 6.0（即将成为 Windows .NET Server 的一个组件）中，默认情况下用户编写的代码不会作为 SYSTEM 运行。基于这样的认识，即开发人员确实会犯错误，Web 服务器就减少赋予代码的权限而提供的任何帮助都是有益的，以免万一代码中存在安全问题。
[1] [2] [3] [4] [5]
下面是另外一个 COM 程序员可能遇到的隐患。COM 有一个不好的倾向就是敷衍线程。如果您调用一个进程内 COM 服务器，而其线程模型与调用线程的模型不匹配，则 COM 会在另一个线程上执行调用。COM 不会传播调用者线程上的模拟标记，这样结果就是调用会在进程的安全环境中执行，而不是在调用线程的安全环境中。多么令人吃惊！
下面是另一个由模拟带来的隐患的情况。假设您的服务器接受通过命名管道、DCOM 或 RPC 发送的请求。您对客户端进行身份验证并模拟它们，通过模拟以它们的名义打开内核对象。而您又忘了在客户端断开连接时关闭其中的一个对象（例如一个文件）。当下一个客户端进入时，您又对其进行身份验证和模拟，猜猜会发生什么？您仍然可以访问上一个客户端“遗漏”的文件，即使新的客户端并没有获得访问该文件的权限。出于运行性能的原因，内核仅在第一次打开对象时对其执行访问检查。即使您后来因为模拟其他用户而更改了安全环境，您还是可以访问此文件。 以上提及的这些情况都是为了提醒一点，即模拟为服务器开发人员提供了方便，但这种方便却具有很大隐患。在您采用一个模拟标记运行程序时，务必要对自己的代码多加注意。
，程序员的“十大安全技巧”
上一篇：复杂算式一键搞定
《程序员的“十大安全技巧”》相关文章
- 程序员的“十大安全技巧”
- › 程序员的“十大安全技巧”
- 在百度中搜索相关文章：程序员的“十大安全技巧”
- 在谷歌中搜索相关文章：程序员的“十大安全技巧”
- 在soso中搜索相关文章：程序员的“十大安全技巧”
- 在搜狗中搜索相关文章：程序员的“十大安全技巧”
tag: 电脑安全，电脑安全防护,电脑安全设置，维修资料 - 电脑维修 - 电脑安全