五种常见的ASP.NET应用程序安全缺陷

　　下面给出了五个例子，阐述如何按照上述建议增强应用程序的安全性。这些例子示范了代码中可能出现的缺陷，以及它们带来的安全风险、如何改写最少的代码来有效地降低攻击风险。
1 篡改参数
◎ 使用ASP.NET域验证器
盲目信任用户输入是保障Web应用安全的第一敌人。用户输入的主要来源是HTML表单中提交的参数，如果不能严格地验证这些参数的合法性，就有可能危及服务器的安全。
下面的C#代码查询后端SQL Server数据库，假设user和password变量的值直接取自用户输入：
SqlDataAdapter my_query = new SqlDataAdapter(
　"SELECT * FROM accounts WHERE acc_user='" + user + "' AND acc_password='" + password, the_connection); 
从表面上看，这几行代码毫无问题，实际上却可能引来SQL注入式攻击。攻击者只要在user输入域中输入“OR 1=1”，就可以顺利登录系统，或者只要在查询之后加上适当的调用，就可以执行任意Shell命令：
'; EXEC master..xp_cmdshell(Oshell command here')-- 
■ 风险分析
在编写这几行代码时，程序员无意之中作出了这样的假定：用户的输入内容只包含“正常的”数据——合乎人们通常习惯的用户名字、密码，但不会包含引号之类的特殊字符，这正是SQL注入式攻击能够得逞的根本原因。黑客们可以借助一些具有特殊含义的字符改变查询的本意，进而调用任意函数或过程。
■ 解决方案
域验证器是一种让ASP.NET程序员对域的值实施限制的机制，例如，限制用户输入的域值必须匹配特定的表达式。
要防止上述攻击行为得逞，第一种办法是禁止引号之类的特殊字符输入，第二种办法更严格，即限定输入域的内容必须属于某个合法字符的集合，例如“[a-zA-Z0-9]*”。
2 篡改参数之二
◎ 避免验证操作的漏洞
然而，仅仅为每个输入域引入验证器还不能防范所有通过修改参数实施的攻击。在执行数值范围检查之时，还要指定正确的数据类型。
也就是说，在使用ASP.NET的范围检查控件时，应当根据输入域要求的数据类型指定适当的Type属性，因为Type的默认值是String。
＜!-- 要求输入值必须是1-9之间的数字 --＞
＜asp:RangeValidator ... MinimumValue="1" MaximumValue="9" .../＞ 
■ 风险分析
由于没有指定Type属性值，上面的代码将假定输入值的类型是String，因此RangeValidator验证器只能确保字符串由0-9之间的字符开始，“0abcd”也会被认可。
■ 解决方案
要确保输入值确实是整数，正确的办法是将Type属性指定为Integer：
＜!-- 要求输入值必须是1-9之间的数字 --＞
＜asp:RangeValidator ... MinimumValue="1"
MaximumValue="9" Type="Integer"  
3 信息泄漏
◎ 让隐藏域更加安全
在ASP.NET应用中，几乎所有HTML页面的__VIEWSTATE隐藏域中都可以找到有关应用的信息。由于__VIEWSTATE是BASE 64编码的，所以常常被忽略，但黑客可以方便地解码BASE 64数据，用不着花什么力气就可以得到__VIEWSTATE提供的详细资料。
■ 风险分析
默认情况下，__VIEWSTATE数据将包含：
⑴ 来自页面控件的动态数据。
⑵ 程序员在ViewState中显式保存的数据。
⑶ 上述数据的密码签字。
■ 解决方案
设置EnableViewStatMAC="true"，启用__VIEWSTATE数据加密功能。然后，将machineKey验证类型设置成3DES，要求ASP.NET用Triple DES对称加密算法加密ViewState数据。
4 SQL注入式攻击
◎ 使用SQL参数API
正如前文“篡改参数”部分描述的，攻击者可以在输入域中插入特殊字符，改变SQL查询的本意，欺骗数据库服务器执行恶意的查询。
■ 风险分析
恶意查询有可能获取后端数据库保存的任何信息，例如客户信用卡号码的清单。
■ 解决方案
除了前面介绍的办法——用程序代码确保输入内容只包含有效字符，另一种更加健壮的办法是使用SQL参数API（例如ADO.NET提供的API），让编程环境的底层API（而不是程序员）来构造查询。
使用这些API时，程序员或者提供一个查询模板，或者提供一个存储过程，然后指定一系列的参数值，由底层API将参数值嵌入到查询模板，然后将构造出来的查询提交给服务器查询。这种办法的好处是确保参数能够正确地嵌入，例如，系统将对引号进行转义处理，从根本上杜绝SQL注入式攻击的发生。同时，在表单中引号仍是一个允许输入的有效字符，这也是使用底层API的一个优点。
按照这种思路修改前文“篡改参数”部分的例子，结果如下：
SqlDataAdapter my_query = new SqlDataAdapter("SELECT * FROM accounts
WHERE acc_user= @user AND acc_password=@pass", the_connection);
SqlParameter userParam = my_query.Select_Command.Parameters.Add(
"@user",SqlDb.VarChar,20);
userParam.Value=user;
SqlParameter passwordParam = my_query.Select_Command.Parameters.Add(
"@",SqlDb.VarChar,20);
passwordParam.Value=password; 
5 跨站脚本执行
◎ 对外发的数据进行编码
跨站脚本执行（Cross-site scripting）是指将恶意的用户输入嵌入到应答（HTML）页面。例如，下面的ASP.NET页面虽然简单，却包含着一个重大的安全缺陷：
＜%@ Page Language="vb" %＞
＜asp:Label id="Label1" runat="server"＞
标签文字
＜/asp:Label＞
＜form method="post" runat="server" ID="Form1"＞
请在此处输入反馈信息
＜asp:Textbox ID="feedback" runat="server"/＞
＜asp:Button id="cmdSubmit" runat="server"
Text="提交!" OnClick="do_feedback"＞
＜/asp:Button＞
＜/form＞
＜script runat="server"＞
Sub do_feedback(sender As Object, e As System.EventArgs)
Label1.Text=feedback.Text
End Sub
＜/script＞ 
■ 风险分析
攻击者可以用JavaScript代码构造一个恶意的查询，点击链接时JavaScript就会运行。举例来说，脚本可以通过下面的用户输入来嵌入：
＜script＞alert(document.cookie)
＜/script＞ 
■ 解决方案
在一个双层的安全体系中，对HTML页面中出现的外发用户数据执行输入验证和HTML编码，确保浏览器只把用户输入数据当成纯粹的文本，而不是其他具有特殊含义的内容，例如HTML代码、JavaScript脚本。
对于本例，只要加入一个HtmlEncode调用即可：
Label1.Text=Server.HtmlEncode(feedback.Text) 
这样，应答HTML流将包含用户输入内容的HTML编码版本，也就是说，浏览器不会执行用户输入的JavaScript代码，因为根本不存在HTML的“＜SCRIPT＞”标记，用户输入的“＜”和“＞”字符已经被替换成HTML编码版本，即“＜”和“＞”。