ASP.NET中如何防范SQL注入式攻击

[aoyunbaobei]

一、什么是SQL注入式攻击？
　　
　　所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：
　　
　　⑴ 某个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，非常适合于对输入数据进行消毒处理。
　　
　　⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。

[qiandeng]

参数化查询 或者是sp 可以有效避免这种情况
没有必要 不要拼接sql语句

[以专业开发人员为伍]

其实看到过不少相当“恶心”的字符串过滤做法。

凭什么用户不能输入单引号、两个减号等等符号？这明明是编程问题，不应该惩罚软件用户。

如果要拼接SQL命令，那么你可以写：

var sql="SELECT * from Users WHERE login = '"+ txtLogin.Text.Replace(“\'","\'\'")+
"' AND password='"+txtPassword.Text.Replace(“\'","\'\'")+"'";

这里，用户实际上可以输入任何符号，完全可以输入单引号和连字符。我们看到过多的所谓范例是号称“过滤”字符的做法，一定不要照抄那些过分技术化（其实丧失了全面的功能来炫技）做法。

对于接受用户输入的字符串参数，采用上述方法。对于其它类型，采用首先强类型转换的方法，例如：

var sql="SELECT Top "+ int.Parse(txtCount.Text).ToString() from Users WHERE login = '"+ txtLogin.Text.Replace(“\'","\'\'")+ "' AND password='"+txtPassword.Text.Replace(“\'","\'\'")+"'";

除非你要求用户直接录入sql语句，否则，只要是用户录入的仅仅是参数，那么仅需要上述两个简单易行的做法就够了。


当然，使用参数（SqlParameter或者DbParameter类型对象）为sql命令提供参数是ADO.NET中最好的查询参数处理做法。而使用Linq则根本超出了ADO.NET，它本身已经是面向对象的了，也就没有了注入问题（底层类库防注入）。

[以专业开发人员为伍]

只有两点：字符串参数要替换一下单引号，非字符串参数要强类型转换一下。这就防止了非法SQL语句被数据库执行，不用考虑过多，要是影响程序设计（例如限制了用户输入某些符号、字符、输入长度）或者增加了编写的代码，就得不尝试了。

最基本的一定做到，但是不用考虑过多技巧。

[jiezi316]

不久前也有个类似的帖子。
拼接是也可以防止SQL注入，不用过滤什么特殊字符。
其实MSSQL已经考虑到了这个问题。可以查查SP_EXECUTESQL系统过程的参数含义，里面可以对拼接的字符串中的占位符进行动态替换。
如下

declare @userid int 
set @userid = 1 
declare @sqlStr nvarchar(1000),@param nvarchar(400) 
set @sqlStr='select * from table where [userid]=@tuserid' //这里可以拼接字符串,我这里简单点哈 
set @param='@tuserid int' 
execute sp_executesql @sqlstr,@param,@tuserid=@userid     //变量动态替换 用@userid替换@tuserid

[FishFlying1985]

好
不错
支持

[以专业开发人员为伍]

我说的两个注意点，第一个是T-SQL语法规定，所以根本不是为了防注入，连语法都拼错了就无所谓防注入了。只有第二个才是防注入。

[以专业开发人员为伍]

[Quote=引用 33 楼 jiezi316 的回复:]
declare @userid int
set @userid = 1
declare @sqlStr nvarchar(1000),@param nvarchar(400)
set @sqlStr='select * from table where [userid]=@tuserid' //这里可以拼接字符串,我这里…
[/Quote]

这里没有拼接字符串。拼接的版本是：

declare @userid nvarchar(100)
set @userid = 1
declare @sqlStr nvarchar(1000),@param nvarchar(400)
set @sqlStr='select * from table where [userid]='+@tuserid //这里可以拼接字符串,我这里…

[jiezi316]

比如按照用户名条件搜索，如果有就按条件搜索，没有就搜索全部的（拼接法,不高率合理性哈）：
declare @whereStr nvarchar(500),@username nvarchar(20)
set @username='*****';

if(@username<>'')
set @whereStr = 'where [username]=@tuserName'
else
set @whereStr = '';
declare @sqlStr nvarchar(1000),@param nvarchar(400)
set @sqlStr='select * from table '+@whereStr
set @param='@tuserName nvarchar(20)'
execute sp_executesql @sqlstr,@param,@tusername=@username

[qilinshu]

一般使用存储过程的话不容易被sql注入吧？

[sonicryu]

不错!! 一般用单引号替换,不要开xpcmdshell

[seaer06]

用存储过程.

[kent55782]

procedure
语法
create proc 存储过程名

[zheng520]

我的防注入方式是两种结合
一、使用危险字符过滤
二、使用带参数的param 非存储过程版的

至于存储过程的，我很不常用，毕竟在开发过程中，很少有公司愿意买服务器，去买空间的话，人家又不给你写存储过程

[stning]

[Quote=引用 15 楼 dropping 的回复:]
mark
[/Quote]

[satans18]

全部参数化不就行了么

[datahandler2]

SP1234说的是很有理,不过老实讲多数人应该还是用参数化来防止注入的.
另外还有相当多的人仍要变态的过滤方法.其实怎么讲.从开发心里上,有的人还是比较喜欢用那种同样的过滤方法.比较心里踏实.
当然SP1234说的方法也确实挺不错.

[小范f-li.cn]

好很好非常好!~

[ruolins]

参数化查询。。。

[bigbigwife]

目前自己还没有考虑的这么仔细，所以要深度mark大家都说的很好啊

[a13951845000]

mark