转自：
http://hi.baidu.com/liulin0712/blog/item/37ad9118b70e860e35fa41d3.html大家存在5点误区：
1、sql注入比较难防，需要替换select,delete等一打字符
其实对于字符型替换再多都没有替换单引号为两个单引号来的好！对于数字型替换再多都没有用，一定要类型转换。
2、忽略DropDownList传来的东西
其实是不对的，一切客户端的东西都是不可信任的，select下拉框也是！因为可以自己做一个htm提交到服务器。
3、access比sqlserver不安全
安全不安全关键看怎么用，如果sqlserver还是像access一样用，一个sa帐户的话，很明显，sqlserver比access不安全，可以直接得到表名和字段名！access反而倒安全点了，因为只能通过逐位猜解得到。
4、网站没有显示出错信息就说明网站是安全的
当有记录的时候显示记录，没有记录的时候显示找不到任何记录，通过这两种状态就可以猜解字段名了，所以网页不出错不能说明是安全的
5、忽略post提交的信息
很多人对url上传递的东西过滤严格，对于post的东西不理不睬是不对的，post的东西更加容易被注入，因为一般字段比较多
在asp.net中强烈建议通过参数来实现sql而不是sql拼接，因为就算你每一个都过滤百密难有疏
比如：
SqlConnection conn=new SqlConnection(System.Configuration.ConfigurationSettings.AppSettings["conn"]);
SqlCommand comm=new SqlCommand("update tb1 set vName=@vName,iAge=@iAge where ID=@id",conn);
SqlParameter parm1=new SqlParameter("@vName",SqlDbType.NVarChar,50);
parm1.Value=((TextBox)e.Item.FindControl("name")).Text;
SqlParameter parm2=new SqlParameter("@iAge",SqlDbType.Int);
parm2.Value=((TextBox)e.Item.FindControl("age")).Text;
SqlParameter parm3=new SqlParameter("@id",SqlDbType.Int);
parm3.Value=this.DataGrid1.DataKeys[e.Item.ItemIndex];
comm.Parameters.Add(parm1);
comm.Parameters.Add(parm2);
comm.Parameters.Add(parm3);
conn.Open();
comm.ExecuteNonQuery();
conn.Close();
这样的代码看起来舒服而且又安全，何乐不为？
| 【导读】本文介绍了五种常见的ASP.NET应用程序安全缺陷 | |
|
|
一、不能盲目相信用户输入
在Web应用开发中，开发者最大的失误往往是无条件地信任用户输入，假定用户（即使是恶意用户）总是受到浏览器的限制，总是通过浏览器和服务器交互，从而打开了攻击Web应用的大门。实际上，黑客们攻击和操作Web网站的工具很多，根本不必局限于浏览器，从最低级的字符模式的原始界面（例如telnet），到CGI脚本扫描器、Web代理、Web应用扫描器，恶意用户可能采用的攻击模式和手段很多。
因此，只有严密地验证用户输入的合法性，才能有效地抵抗黑客的攻击。应用程序可以用多种方法（甚至是验证范围重叠的方法）执行验证，例如，在认可用户输入之前执行验证，确保用户输入只包含合法的字符，而且所有输入域的内容长度都没有超过范围（以防范可能出现的缓冲区溢出攻击），在此基础上再执行其他验证，确保用户输入的数据不仅合法，而且合理。必要时不仅可以采取强制性的长度限制策略，而且还可以对输入内容按照明确定义的特征集执行验证。下面几点建议将帮助你正确验证用户输入数据：
⑴ 始终对所有的用户输入执行验证，且验证必须在一个可靠的平台上进行，应当在应用的多个层上进行。
⑵ 除了输入、输出功能必需的数据之外，不要允许其他任何内容。
⑶ 设立“信任代码基地”，允许数据进入信任环境之前执行彻底的验证。
⑷ 登录数据之前先检查数据类型。
⑸ 详尽地定义每一种数据格式，例如缓冲区长度、整数类型等。
⑹ 严格定义合法的用户请求，拒绝所有其他请求。
⑺ 测试数据是否满足合法的条件，而不是测试不合法的条件。这是因为数据不合法的情况很多，难以详尽列举。
二、五种常见的ASP.NET安全缺陷
下面给出了五个例子，阐述如何按照上述建议增强应用程序的安全性。这些例子示范了代码中可能出现的缺陷，以及它们带来的安全风险、如何改写最少的代码来有效地降低攻击风险。
2.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.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"
2.3 信息泄漏
◎ 让隐藏域更加安全
在ASP.NET应用中，几乎所有HTML页面的__VIEWSTATE隐藏域中都可以找到有关应用的信息。由于__VIEWSTATE是BASE 64编码的，所以常常被忽略，但黑客可以方便地解码BASE 64数据，用不着花什么力气就可以得到__VIEWSTATE提供的详细资料。
■ 风险分析
默认情况下，__VIEWSTATE数据将包含：
⑴ 来自页面控件的动态数据。
⑵ 开发者在ViewState中显式保存的数据。
⑶ 上述数据的密码签字。
■ 解决方案
设置EnableViewStatMAC="true"，启用__VIEWSTATE数据加密功能。然后，将machineKey验证类型设置成3DES，要求ASP.NET用Triple DES对称加密算法加密ViewState数据。
2.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;
2.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"＞
请在此处输入反馈信息＜br＞
＜asp:Textbox ID="feedback" runat="server"/＞＜br＞
＜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编码版本，即“＜”和“＞”。
三、使用自动安全测试工具
由于客户需求不断变化，一些单位平均每三个月就要部署新的应用，同时由于人员流动，所以对开发者快速开发健壮的、高质量的代码寄予很高的期望。虽然对所有开发者进行代码安全技术的培训是十分必要的，但不可否认，自动检测代码安全漏洞的工具也有助于快速开发安全的应用程序。
到目前为止，开发者常用的工具只能涵盖功能测试的特定方面，例如性能测试，BUG/故障点侦查。人工检查代码有着许多与生俱来的局限，而且要求开发者具有丰富的代码安全经验，所以对于编写高质量的应用来说，面向应用程序安全及其在恶意环境下行为的工具也是十分关键的。
要迅速提高应用的质量和安全性，最有效的办法是给开发者提供一个自动测试应用的工具。如果在单元测试期间，工具能够检测出应用的安全缺陷，并将修补建议嵌入到代码之中，开发者就能立即找出代码中存在的错误，不仅方便了现有错误的修改，而且也有助于避免将来再犯同样的错误，不断地提高代码抗御攻击的能力。
结束语：Web服务应用正在爆炸式增长，越来越多的应用被推出到防火墙之外，安全性脆弱的Web应用面临的风险也只会有增无减。同时，为了在紧迫的时限之前快速完成应用开发，开发者面临的压力也越来越大。注重编写代码时的安全问题，同时投入必要的资源，这样才能为未来的Web服务应用做好准备，同时确保当前应用的高质量。只有从应用的出生之日开始就采取正确的措施来确保其安全性，才能构造出高质量、安全的应用。 |
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder( SELECT * from Users WHERE login = ) .Append(txtLogin.Text).Append( AND password=) .Append(txtPassword.Text).Append();
⑶ 攻击者在用户名字和密码输入框中输入或1=1之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = or 1=1 AND password = or 1=1。
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。 如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
如何防范？
好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = or 1=1 AND password = or 1=1”显然会得到与“SELECT * from Users WHERE login = or 1=1 AND password = or 1=1”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = mas -- AND password =”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理
