程序员十大安全技巧

　　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 遵循了这一安装建议，您可以在这个月发布的 Wayne Berry 的文章“Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes”中读到相关内容。这种安装策略背后的思想是您不会注意自己并未使用的服务，如果这些服务正在运行，则可能被其他人利用。如果默认安装某功能，则它应在最小授权原则下运行。也就是说，除非必要，否则不要允许使用管理员权限运行应用程序。最好遵循这一忠告。

　　7. 使用最小授权原则

　　出于若干原因，操作系统和公共语言运行时有一个安全策略。很多人以为此安全策略存在的主要原因是防止用户有意破坏：访问他们无权访问的文件、重新配置网络以达到他们的要求以及其他恶劣行为。的确，这种来自内部的攻击很普遍，也需要防范，但还有另一个原因需要严守这一安全策略。即在代码周围建立起防范壁垒以防止用户有意或（正如经常发生的）无意的操作对网络造成严重破坏。例如，通过电子邮件下载的附件在 Alice 的机器上执行时被限制为只能访问 Alice 可以访问的资源。如果附件中含有特洛伊木马，那么好的安全策略就是限制它所能产生的破坏。 当您设计、建立并部署服务器应用程序时，您不能假设所有请求都来自合法用户。如果一个坏家伙发送给您一个恶意请求（但愿不会如此）并使您的代码产生恶劣操作，您会希望您的应用程序拥有所有可能的防护来限制损害。因此我们认为，您的公司实施安全策略不仅是因为它不信任您或您的代码，同时也是为了保护不受外界有企图的代码的伤害。

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

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