设计安全的Visual Studio.NET互联网服务
使用Visual Studio.NET开发的Web服务一般采用C#、VB.NET等可治理性编程语言编写，这些语言具有较强的安全性。可治理代码有助于减少缓冲溢出等安全缺陷，通过其提供的代码访问权限功能，编程人员能够限制代码的权限，防止黑客将应用程序代码作为恶意代码使用。
在经过对Web服务的安全性进行评估后，我发现VS.NET Web服务的设计人员轻易犯二个致命的错误，这二个错误都与Web服务和SQL Server、Oracle等数据库服务器之间的连接有关。令人讨厌的是，这些错误在Java、ASP、C++、和Visual Basic应用程序中都会出现。但好在它们很轻易被修复，这也是我将在本篇文章中要讨论的问题。
错误1：使用系统治理员帐户连接数据库服务器
几乎我见过的所有Web服务的SQL软件中都含有以系统治理员身份与数据库连接的代码，这是一个很常见的错误，仔细地考虑一下，我们曾多少次地见过下面的代码：
strConnection = "data source=DBServer;uid=sa;pwd="
连接到数据库服务器上的用户的身份是sa（SQL Server的系统治理员帐户），密码是空的。不使用密码轻易造成的恶果广大读者也一定明白，但现在我关注的是sa帐户的问题。
最少权限是一条重要的安全准则，它要求我们使用的帐户只具有我们完成任务所必需的权限。因此，假如我们的应用程序只查询几个表，并更新另一个表，完成这样的任务需要使用sa帐户？当然，sa能够对表完成查询和更新操作，但它同样能够完成一些我们并不希望它执行的任务，它能够删除任何表、调用任意的存储过程、调整每个表中的数据、定义新的数据库等。因此，我们绝不能使用sa帐户来完成简单的查询和更新操作。它的功能太强大了，能够对数据库执行任意的操作，应用程序中的一个小缺陷就可能使用户受到黑客的攻击。
在与数据库进行连接时一定要符合最少权限准则。尽管这样会需要较长的时间，但黑客要攻击系统则需要更长的时间。。此外，不要在应用程序中存储连接字符串，应当从外部资源中获取连接字符串，这样，不但能够提高系统的安全性还提高了系统的可维护性。
更多的请看：http://www.QQread.com/windows/2003/index.Html
错误2：手工编写SQL语句
初看下面的代码，它似乎不会有什么问题：
strSQL = "select sum(cost) from sales where id='" + id + "'";
你的软件中有这样的代码吗？一项调查显示，80%的编程人员在软件中编写过类似的代码。这类代码的问题是它提供了用户使用的id变量，使得黑客可能将id变量设置为其他的SQL语句。
例如，黑客可以将id变量设置为下面的值：
1' drop table sales --
上面的代码将变为下面的形式：
select sum(cost)
from sales
where id='1' drop table sales -- '
这一代码将执行一个查询，查找id = 1的任意行，该行可能存在也可能不存在，而后，销售数据库表会被卸载，甚至被删除。
解决办法
下面用C#编写的代码说明了如何利用广泛的抵御攻击的能力（在第一种防御措施失效后，还能提供多种防御措施）减少系统被攻击的危险：
[WebMethod]
public decimal GetSalesFigures(string CustomerID) {
SqlCommand cmd = null;
decimal sum = 0.0;
try {
// 检查CustomerID是否有效，CustomerID必须是二位字符再加6位数字，而且对大小写敏感
Regex reg = new Regex(@"^[a-z]{2}\d{6}$","i");
if (!reg.Match(CustomerID).SUCcess)
throw new SoapException("Invalid Sales ID",
SoapException.ClientFaultCode);
// 从外部位置获取连接字符串
SqlConnection sqlConn= new SqlConnection(ConnectionString);
// 向存储过程中添加销售ID
string str="spGetSalesFigures";
cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ID",CustomerID);
cmd.Connection.Open();
sum = (decimal)cmd.ExecuteScalar();
} catch (Exception e) {
throw new SoapException(e.Message,
SoapException.ClientFaultCode);
} finally {
// 失败后关闭连接
if (cmd != null)
cmd.Connection.Close();
}
return sum;
}
// 从外部XML配置文件获取连接字符串
static internal string ConnectionString {
get {
XmlTextReader reader = null;
string connstring = "";
try {
reader = new XmlTextReader (@"c:\config\config.Xml");
while (reader.Read()) {
if (reader.NodeType == XmlNodeType.Element &&
reader.Name == "connectstring") {
connstring =
reader.GetAttribute("value");
}
}
} finally {
if (reader != null)
reader.Close();
}
return connstring;
}
}
下面我们来仔细分析上面代码中的安全策略。
首先，也是最重要的，上面的代码使用了规则表达式来验证CustomerID，看它是否是由2个字符加6位数字组成的，假如不是，则CustomerID是无效的。
其次，上面的代码从一个外部XML文件获取连接字符串，所使用的代码如下：
每个连接都是通过一个单一的身份生成的，而且都有密码。不仅如此，在SQL Server中，我将该帐户配置成只能访问它需要使用的数据表和存储过程。另外，该帐户的访问权限是只读和可执行，它能够完成的操作受到较大的限制。还需要提到的一点是，外部的XML文件存储在Web文件空间之外，这是为了防止万一黑客能够读取目录中的文件或能够访问应用程序的二进制目录。
第三，应用程序没有使用手工的方式编写SQL字符串，它调用了一个存储过程，并使用参数化查询方式设置过程的参数。这样做有二个好处：它能够阻止SQL入侵攻击，由于其逻辑是保存在一个过程中的，黑客无法通过读取查询字符串轻易地确定数据库对象的名字。
第四，一定要及时地关闭数据库连接。在上面的代码中，关闭帐户与SQL Server之间连接的代码被放在了finally程序块中。无论是否有异常发生，finally程序块中的代码总是能够被执行到，因此，帐户与SQL Server之间连接就一定能够被关闭。由于到SQL Server之间连接的数量是有一定限制的，因此应该十分小心地控制连接的使用。否则，黑客就能够通过创建大量的连接而发动DOS攻击，从而使有效客户不能获得连接。将关闭连接的代码放在finally程序块中就意味着连接总是能够被及时地关闭。
