安全专家 Michael Howard 和 Keith Brown 提出了十条技巧来帮助您解脱困境。
安全问题涉及许多方面。安全风险可能来自任何地方。您可能编写了无效的错误处理代码，或者在赋予权限时过于慷慨。您可能忘记了在您的服务器上正在运行什么服务。您可能接受了所有用户输入。如此等等。为使您在保护自己的计算机、网络和代码方面有个良好开端，这里展示了十条技巧，遵循这些技巧可以获得一个更安全的网络策略。
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: SaferString 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[m
该 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 Information Services (IIS) 6.0 遵循了这一安装建
