安全问题涉及许多方面。安全风险可能来自任何地方。您可能编写了无效的错误处理代码，或者在赋予权限时过于慷慨。您可能忘记了在您的服务器上正在运行什么服务。您可能接受了所有用户输入。如此等等。为使您在保护自己的计算机、网络和代码方面有个良好开端，这里展示了十条技巧，遵循这些技巧可以获得一个更安全的网络策略。
1. 信任用户的输入会将自己置于险境
即使不阅读余下的内容，也要记住一点，“不要信任用户输入”。如果您总是假设数据是有效的并且没有恶意，那么问题就来了。大多数安全薄弱环节都与攻击者向服务器提供恶意编写的数据有关。
信任输入的正确性可能会导致缓冲区溢出、跨站点脚本攻击、SQL 插入代码攻击等等。
让我们详细讨论一下这些潜在攻击方式。
2. 防止缓冲区溢出
当攻击者提供的数据长度大于应用程序的预期时，便会发生缓冲区溢出，此时数据会溢出到内部存储器空间。缓冲区溢出主要是一个 C/C++ 问题。它们是种威胁，但通常很容易修补。我们只看到过两个不明显且难以修复的缓冲区溢出。开发人员没有预料到外部提供的数据会比内部缓冲区大。溢出导致了内存中其他数据结构的破坏，这种破坏通常会被攻击者利用，以运行恶意代码。数组索引错误也会造成缓冲区下溢和超限，但这种情况没那么普遍。
请看以下 C++ 代码片段：
void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
char cBuffDest[32];
memcpy(cBuffDest,cBuffSrc,cbBuffSrc);
}
问题在哪里？事实上，如果 cBuffSrc 和 cbBuffSrc 来自可信赖的源（例如不信任数据并因此而验证数据的有效性和大小的代码），则这段代码没有任何问题。然而，如果数据来自不可信赖的源，也未得到验证，那么攻击者（不可信赖源）很容易就可以使 cBuffSrc 比 cBuffDest 大，同时也将 cbBuffSrc 设定为比 cBuffDest 大。当 memcpy 将数据复制到 cBuffDest 中时，来自 DoSomething 的返回地址就会被更改，因为 cBuffDest 在函数的堆栈框架上与返回地址相邻，此时攻击者即可通过代码执行一些恶意操作。
弥补的方法就是不要信任用户的输入，并且不信任 cBuffSrc 和 cbBuffSrc 中携带的任何数据：
void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
const DWORD cbBuffDest = 32;
char cBuffDest[cbBuffDest];
#ifdef _DEBUG
memset(cBuffDest, 0x33, cbBuffSrc);
#endif
memcpy(cBuffDest, cBuffSrc, min(cbBuffDest, cbBuffSrc));
}
此函数展示了一个能够减少缓冲区溢出的正确编写的函数的三个特性。首先，它要求调用者提供缓冲区的长度。当然，您不能盲目相信这个值！接下来，在一个调试版本中，代码将探测缓冲区是否真的足够大，以便能够存放源缓冲区。如果不能，则可能触发一个访问冲突并把代码载入调试器。在调试时，您会惊奇地发现竟有如此多的错误。最后也是最重要的是，对 memcpy 的调用是防御性的，它不会复制多于目标缓冲区存放能力的数据。
在 Windows? Security Push at Microsoft（Microsoft Windows? 安全推动活动）中，我们为 C 程序员创建了一个安全字符串处理函数列表。您可以在 Strsafe.h: Safer String Handling in C（英文）中找到它们。
3. 防止跨站点脚本
跨站点脚本攻击是 Web 特有的问题，它能通过单个 Web 页中的一点隐患危害客户端的数据。想像一下，下面的 ASP.NET 代码片段会造成什么后果：
＜script language=c#＞
Response.Write("您好，" + Request.QueryString("name"));
＜/script＞
有多少人曾经见过类似的代码？但令人惊讶的是它有问题！通常，用户会使用类似如下的 URL 访问这段代码： http://explorationair.com/welcome.aspx?name=Michael
该 C# 代码认为数据始终是有效的，并且只是包含了一个名称。但攻击者会滥用这段代码，将脚本和 HTML 代码作为名称提供。如果输入如下的 URL http://northwindtraders.com/welcome.aspx?name=＜script＞alert('您好！'); ＜/script＞
您将得到一个网页，上面显示一个对话框，显示“您好！”。您可能会说，“那又怎样？”想像一下，攻击者可以诱导用户点击这样的链接，但查询字符串中却包含一些真正危险的脚本和 HTML，由此会得到用户的 cookie 并把它发送到攻击者拥有的网站；现在攻击者便获得了您的私人 cookie 信息，或许会更糟。
要避免这种情况，有两种方法。第一种是不信任输入，并严格限制用户名所包含的内容。例如，可以使用正则表达式检查该名称是否只包含一个普通的字符子集，并且不太大。以下 C# 代码片段显示了完成这一步骤的方法：
Regex r = new Regex(@"^[w]{1,40}$");
if (r.Match(strName).Success) {
// 好！字符串没问题
} else {
// 不好！字符串无效
}
这段代码使用正则表达式验证一个字符串仅包含 1 到 40 个字母或数字。这是确定一个值是否正确的唯一安全方法。
HTML 或脚本不可能蒙混过此正则表达式！不要使用正则表达式寻找无效字符并在发现这种无效字符后拒绝请求，因为容易出现漏掉的情况。 第二种防范措施是对所有作为输出的输入进行 HTML 编码。这会减少危险的 HTML 标记，使之变成更安全的转义符。您可以在 ASP.NET 中使用 HttpServerUtility.HtmlEncode，或者在 ASP 中使用 Server.HTMLEncode 转义任何可能出现问题的字符串。
4. 不要请求 sa 权限
我们要讨论的最后一种输入信任攻击是 SQL 插入代码。许多开发人员编写这样的代码，即获取输入并使用该输入来建立 SQL 查询，进而与后台数据存储（如 Microsoft? SQL Server? 或 Oracle）进行通信。
请看以下代码片段：
void DoQuery(string Id) {
SqlConnection sql=new SqlConnection(@"data source=localhost;" +
"user id=sa;password=password;");
sql.Open();
sqlstring= "SELECT hasshipped" +
" FROM shipping WHERE id='" + Id + "'";
SqlCommand cmd = new SqlCommand(sqlstring,sql);
???
这段代码有三个严重缺陷。首先，它是以系统管理员帐户 sa 建立从 Web 服务到 SQL Server 的连接的。不久您就会看到这样做的缺陷所在。第二点，注意使用“password”作为 sa 帐户密码的聪明做法！
但真正值得关注的是构造 SQL 语句的字符串连接。如果用户为 ID 输入 1001，您会得到如下 SQL 语句，它是完全有效的。
SELECT hasshipped FROM shipping WHERE id = '1001'
但攻击者比这要有创意得多。他们会为 ID 输入一个“'1001' DROP table shipping --”，它将执行如下查询：
SELECT hasshipped FROM
shipping WHERE id = '1001'
DROP table shipping -- ';
它更改了查询的工作方式。这段代码不仅会尝试判断是否装运了某些货物，它还会继续 drop（删除）shipping 表！操作符 -- 是 SQL 中的注释操作符，它使攻击者能够更容易地构造一系列有效但危险的 SQL 语句！
这时您也许会觉得奇怪，怎么任何一个用户都能删除 SQL Server 数据库中的表呢。当然，您是对的，只有管理员才能做这样的工作。但这里您是作为 sa 连接到数据库的，而 sa 能在 SQL Server 数据库上做他想做的任何事。永远不要在任何应用程序中以 sa 连接 SQL Server；正确的做法是，如果合适，使用 Windows 集成的身份验证，或者以一个预先定义的具有适当权限的帐户连接。
修复 SQL 插入代码问题很容易。使用 SQL 存储过程及参数，下面的代码展示了创建这种查询的方法 - 以及如何使用正则表达式来确认输入有效，因为我们的交易规定货运 ID 只能是 4 到 10 位数字：
Regex r = new Regex(@"^d{4,10}$");
if (!r.Match(Id).Success)
throw new Exception("无效 ID");
SqlConnection sqlConn= new SqlConnection(strConn);
string str="sp_HasShipped";
SqlCommand cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ID",Id);
缓冲区溢出、跨站点脚本和 SQL 插入代码攻击都是信任输入问题的示例。所有这些攻击都能通过一种机制来减轻危害，即认为所有输入都是有害的，除非获得证明。
5. 注意加密代码！
下面我们来看些会让我们吃惊的东西。我发现我们检查的安全代码中百分之三十以上都存在安全漏洞。最常见的漏洞可能就是自己的加密代码，这些代码很可能不堪一击。永远不要创建自己的加密代码，那是徒劳的。不要认为仅仅因为您有自己的加密算法其他人就无法破解。攻击者能使用调试器，他们也有时间和知识来确认系统如何工作 - 通常在几小时内就会破解它们。您应该使用 Win32? 的 CryptoAPI，System.Security.Cryptography 命名空间提供了大量优秀且经过测试的加密算法。
6. 减少自己被攻击的可能性
如果没有百分之九十以上的用户要求，则不应默认安装某一功能。Internet">Internet">Internet">Internet Information Services (IIS) 6.0 遵循了这一安装建议，您可以在这个月发布的 Wayne Berry 的文章“Innovations in Internet">Internet">Internet">Internet Information Services Let You Tightly Guard Secure Data and Server Processes”中读到相关内容。这种安装策略背后的思想是您不会注意自己并未使用的服务，如果这些服务正在运行，则可能被其他人利用。如果默认安装某功能，则它应在最小授权原则下运行。也就是说，除非必要，否则不要允许使用管理员权限运行应用程序。最好遵循这一忠告。
7. 使用最小授权原则
出于若干原因，操作系统和公共语言运行时有一个安全策略。很多人以为此安全策略存在的主要原因是防止用户有意破坏：访问他们无权访问的文件、重新配置网络以达到他们的要求以及其他恶劣行为。的确，这种来自内部的攻击很普遍，也需要防范，但还有另一个原因需要严守这一安全策略。即在代码周围建立起防范壁垒以防止用户有意或（正如经常发生的）无意的操作对网络造成严重破坏。例如，通过电子邮件下载的附件在 Alice 的机器上执行时被限制为只能访问 Alice 可以访问的资源。如果附件中含有特洛伊木马，那么好的安全策略就是限制它所能产生的破坏。 当您设计、建立并部署服务器应用程序时，您不能假设所有请求都来自合法用户。如果一个坏家伙发送给您一个恶意请求（但愿不会如此）并使您的代码产生恶劣操作，您会希望您的应用程序拥有所有可能的防护来限制损害。因此我们认为，您的公司实施安全策略不仅是因为它不信任您或您的代码，同时也是为了保护不受外界有企图的代码的伤害。
最小授权原则认为，要在最少的时间内授予代码所需的最低权限。也就是说，任何时候都应在您的代码周围竖起尽可能多的防护墙。当发生某些不好的事情时 - 就象 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 和线程上的模拟标记来进行一个访问检查。如果访问检查失败，本地文件系统会将其报告给文件系统重定向器，然后重定向器向远程客户端发送一个错误。毫无疑问，对文件系统重定向器来说这很方便，因为它只是简单地把请求传给本地文件系统，让它去做自己的访问检查，就好象客户端在本地一样。 这对于文件重定向器这样简单的网关而言，一切良好。但模拟常常用在其他更复杂的应用程序中。以一个 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 服务器就减少赋予代码的权限而提供的任何帮助都是有益的，以免万一代码中存在安全问题。
下面是另外一个 COM 程序员可能遇到的隐患。COM 有一个不好的倾向就是敷衍线程。如果您调用一个进程内 COM 服务器，而其线程模型与调用线程的模型不匹配，则 COM 会在另一个线程上执行调用。COM 不会传播调用者线程上的模拟标记，这样结果就是调用会在进程的安全环境中执行，而不是在调用线程的安全环境中。多么令人吃惊！
下面是另一个由模拟带来的隐患的情况。假设您的服务器接受通过命名管道、DCOM 或 RPC 发送的请求。您对客户端进行身份验证并模拟它们，通过模拟以它们的名义打开内核对象。而您又忘了在客户端断开连接时关闭其中的一个对象（例如一个文件）。当下一个客户端进入时，您又对其进行身份验证和模拟，猜猜会发生什么？您仍然可以访问上一个客户端“遗漏”的文件，即使新的客户端并没有获得访问该文件的权限。出于运行性能的原因，内核仅在第一次打开对象时对其执行访问检查。即使您后来因为模拟其他用户而更改了安全环境，您还是可以访问此文件。 以上提及的这些情况都是为了提醒一点，即模拟为服务器开发人员提供了方便，但这种方便却具有很大隐患。在您采用一个模拟标记运行程序时，务必要对自己的代码多加注意。
10. 编写非管理员用户可以实际使用的应用程序
这确实是最小授权原则的必然结果。如果程序员继续开发这样的代码，使得必须是管理员身份的用户才能在 Windows 上正常运行，我们就不能期望提高系统的安全性。Windows 有一套非常稳定的安全功能，但是如果用户必须具有管理员身份才能进行操作，他们就不能很好地利用这些功能。
您怎样进行改进呢？首先，自己先尝试一下，不以管理员身份运行。您很快就会知道使用没有考虑安全设计的程序的痛苦。有一天，我安装一个由手持设备制造商提供的软件，该软件用于在我的台式机和手持设备之间同步数据。与往常一样，我退出了普通的用户帐户，然后使用内置的管理员帐户再次登录，安装了软件，然后再次登录到普通帐户，并且试图运行软件。结果该应用程序跳出一个对话框，说不能访问某个所需的数据文件，接着便给出一个访问冲突信息。朋友们，这就是某个主流手持设备厂商的软件产品。对这种错误还有什么借口吗？
在运行了来自 http://sysinternals.com（英文）的 FILEMON 之后，我很快发现该应用程序试图打开一个数据文件以进行写入访问，而该文件与应用程序的可执行文件安装在同一目录中。当应用程序如预想的那样安装在 Program Files 目录中时，他们绝不能试图向该目录写入数据。Program Files 具有这样一个限制访问控制策略是有原因的。我们不希望用户写入这些目录，因为这样会很容易让一个用户留下特洛伊木马程序，而让另一个用户去执行。实际上，这个约定是 Windos XP 的基本标志性要求之一。
我们听到太多的程序员给出借口说他们为什么在开发代码时选择作为管理员身份运行。如果我们继续忽略这一问题，只会让事情更糟。朋友们，编辑一个文本文件并不需要管理员权限。编辑或调试一个程序也不需要管理员权限。在您需要管理员权限时，请使用操作系统的 RunAs 功能来运行。
我们听到太多的程序员给出借口说他们为什么在开发代码时选择作为管理员身份运行。如果我们继续忽略这一问题，只会让事情更糟。朋友们，编辑一个文本文件并不需要管理员权限。编辑或调试一个程序也不需要管理员权限。在您需要管理员权限时，请使用操作系统的 RunAs 功能来运行具有较高权限的单独的程序。如果您是在编写给开发人员使用的工具，那么您将对这个群体负有额外的责任。我们需要停止这种编写只有以管理员身份才能运行的代码的恶性循环，要达到这一目标，我们必须从根本上发生改变。