.NET防SQL注入方法
SQL语句
利用SqlCommand传参数的方法：
string strSQL="SELECT * FROM
[user] WHERE user_id=@id";
SqlCommand cmd =
new SqlCommand();
cmd.CommandText =
strSQL;
cmd.Parameters.Add("@id",SqlDbType.VarChar,20).Value=Request["id"].ToString();
过滤禁止运行法：
/// <summary>
/// 过滤SQL语句,防止注入
///
</summary>
/// <param
name="strSql"></param>
/// <returns>0 - 没有注入, 1 -
有注入 </returns>
public int filterSql(string sSql)
{
int srcLen, decLen = 0;
sSql =
sSql.ToLower().Trim();
srcLen = sSql.Length;
sSql = sSql.Replace("exec", "");
sSql = sSql.Replace("delete",
"");
sSql = sSql.Replace("master", "");
sSql =
sSql.Replace("truncate", "");
sSql = sSql.Replace("declare",
"");
sSql = sSql.Replace("create", "");
sSql =
sSql.Replace("xp_", "no");
decLen =
sSql.Length;
if (srcLen == decLen) return 0; else return
1;
}
存储过程
因为在存储过程中就可以设置变量的类型,所以也无需对数据做任何操作
漏洞演示：
http://xxx.xxx.xxx.xxx/xxx.asp?id=17;DROP TABLE D99_Tmp;CREATE TABLE D99_Tmp(subdirectory
VARCHAR(100),depth VARCHAR(100),[file] VARCHAR(100))
禁止后使用SQL 语句中就不能出现“exec, master, delete, truncate,
declare, create, xp_”这些字符。
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
SQL注入攻击是非常令人讨厌的安全漏洞，是所有的web开发人员，不管是什么平台，技术，还是数据层，需要确信他们理解和防止的东西。不幸的是，开发人员往往不集中花点时间在这上面，以至他们的应用，更糟糕的是，他们的客户极其容易受到攻击。
Michael Sutton 最近发表了一篇非常发人深省的帖子，讲述在公共网上这问题是多么地普遍。他用Google的Search
API建了一个C#的客户端程序，寻找那些易受SQL 注入攻击的网站。其步骤很简单：
寻找那些带查询字符串的网站(例如，查询那些在URL里带有 "id=" 的URL)
给这些确定为动态的网站发送一个请求，改变其中的id=语句，带一个额外的单引号，来试图取消其中的SQL语句(例如，如 id=6' )
分析返回的回复，在其中查找象"SQL" 和"query"这样的词，这往往表示应用返回了详细的错误消息(这本身也是很糟糕的)
检查错误消息是否表示发送到SQL服务器的参数没有被正确加码(encoded)，如果如此，那么表示可对该网站进行SQL注入攻击
对通过Google搜寻找到的1000个网站的随机取样测试，他检测到其中的11.3%有易受SQL注入攻击的可能。这非常，非常地可怕。这意味着黑客可以远程利用那些应用里的数据，获取任何没有hashed或加密的密码或信用卡数据，甚至有以管理员身份登陆进这些应用的可能。这不仅对开发网站的开发人员来说很糟糕，而且对使用网站的消费者或用户来说更糟糕，因为他们给网站提供了数据，想着网站是安全的呢。
那么SQL注入攻击到底是什么玩意？
有几种情形使得SQL注入攻击成为可能。最常见的原因是，你动态地构造了SQL语句，却没有使用正确地加了码(encoded)的参数。譬如，考虑这个SQL查询的编码，其目的是根据由查询字符串提供的社会保险号码(social
security number)来查询作者(Authors)：
Dim SSN as String
Dim SqlQuery as String
SSN = Request.QueryString("SSN")
SqlQuery = "SELECT au_lname, au_fname
FROM authors WHERE au_id = '" + SSN + "'"
如果你有象上面这个片断一样的SQL编码，那么你的整个数据库和应用可以远程地被黑掉。怎么会呢？在普通情形下，用户会使用一个社会保险号码来访问这个网站，编码是象这样执行的：
' URL to the page containing the above code
http://mysite.com/listauthordetails.aspx?SSN=172-32-9999
' SQL Query executed against the database
SELECT au_lname, au_fname FROM
authors WHERE au_id = '172-32-9999'
这是开发人员预期的做法，通过社会保险号码来查询数据库中作者的信息。但因为参数值没有被正确地加码，黑客可以很容易地修改查询字符串的值，在要执行的值后面嵌入附加的SQL语句
。譬如，
' URL to the page containing the above code
http://mysite.com/listauthordetails.aspx?SSN=172-32-9999';DROP
DATABASE pubs --
' SQL Query executed against the database
SELECT au_lname, au_fname FROM
authors WHERE au_id = '';DROP DATABASE pubs --
注意到没有，我可以在SSN查询字符串值的后面添加"
';DROP DATABASE pubs -- "，通过
";"字符来终止当前的SQL语句，然后添加了我自己的恶意的SQL语句，然后把语句的其他部分用"--"字符串注释掉。因为我们是手工在编码里构造SQL语句，我们最后把这个字符串传给了数据库，数据库会先对authors表进行查询，然后把我们的pubs数据库删除。"砰(bang)"的一声，数据库就没了！
万一你认为匿名黑客删除你的数据库的结果很坏，但不幸的是，实际上，这在SQL注入攻击所涉及的情形中算是比较好的。一个黑客可以不单纯摧毁数据，而是使用上面这个编码的弱点，执行一个JOIN语句，来获取你数据库里的所有数据，显示在页面上，允许他们获取用户名，密码，信用卡号码等等。他们也可以添加
UPDATE/INSERT 语句改变产品的价格，添加新的管理员账号，真的搞砸你(screw up your
life)呢。想象一下，到月底检查库存时，发现你库房里的实际产品数与你的帐目系统(accounting system)汇报的数目有所不同。。。
那该如何保护你自己？
SQL注入攻击是你需要担心的事情，不管你用什么web编程技术，再说所有的web框架都需要担心这个的。你需要遵循几条非常基本的规则：
1)
在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。大多数的数据API，包括ADO和ADO.NET，有这样的支持，允许你指定所提供的参数的确切类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded了，来避免黑客利用它们。一定要从始到终地使用这些特性。
例如，在ADO.NET里对动态SQL，你可以象下面这样重写上述的语句，使之安全：
Dim SSN as String = Request.QueryString("SSN")
Dim cmd As new SqlCommand("SELECT au_lname, au_fname FROM authors WHERE au_id
= @au_id")
Dim param = new SqlParameter("au_id",
SqlDbType.VarChar)
param.Value = SSN
cmd.Parameters.Add(param)
这将防止有人试图偷偷注入另外的SQL表达式(因为ADO.NET知道对au_id的字符串值进行加码)，以及避免其他数据问题(譬如不正确地转换数值类型等)。注意，VS
2005内置的TableAdapter/DataSet设计器自动使用这个机制，ASP.NET 2.0数据源控件也是如此。
一个常见的错误知觉(misperception)是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。
2) 在部署你的应用前，始终要做安全审评(security review)。建立一个正式的安全过程(formal security
process)，在每次你做更新时，对所有的编码做审评。后面一点特别重要。很多次我听说开发队伍在正式上线(going
live)前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关，推说，"就是一个小小的更新，我们以后再做编码审评好了"。请始终坚持做安全审评。
3) 千万别把敏感性数据在数据库里以明文存放。我个人的意见是，密码应该总是在单向(one-way
)hashed过后再存放，我甚至不喜欢将它们在加密后存放。在默认设置下，ASP.NET 2.0 Membership API
自动为你这么做，还同时实现了安全的SALT 随机化行为(SALT randomization
behavior)。如果你决定建立自己的成员数据库，我建议你查看一下我们在这里发表的我们自己的Membership
provider的源码。同时也确定对你的数据库里的信用卡和其他的私有数据进行了加密。这样即使你的数据库被人入侵(compromised)了的话，起码你的客户的私有数据不会被人利用。
4)
确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。这么做是非常重要的，有助于捕捉住(catch)"就是一个小小的更新，所有不会有安全问题"的情形带来的疏忽，来提供额外的安全层以避免偶然地引进坏的安全缺陷到你的应用里去。
5)
锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限从你的account
payables表来生成报表，那么确认你禁止它对此表的 insert/update/delete 的权限。
SQL注入式攻击
SQL注入式攻击是利用是指利用设计上的漏洞，在目标服务器上运行Sql命令以及进行其他方式的攻击动态生成Sql命令时没有对用户输入的数据进行验证是Sql注入攻击得逞的主要原因。
比如：
如果你的查询语句是select * from admin where username="&user&" and
password="&pwd&""
那么，如果我的用户名是：1 or 1=1
那么，你的查询语句将会变成：
select * from admin where username=1 or 1=1 and password="&pwd&""
这样你的查询语句就通过了，从而就可以进入你的管理界面。
所以防范的时候需要对用户的输入进行检查。特别式一些特殊字符，比如单引号，双引号，分号，逗号，冒号，连接号等进行转换或者过滤。
需要过滤的特殊字符及字符串有：
net user
xp_cmdshell
/add
exec master.dbo.xp_cmdshell
net
localgroup administrators
select
count
Asc
char
mid
:
"
insert
delete from
drop
table
update
truncate
from
%
下面关于解决注入式攻击的防范代码，供大家学习参考！
js版的防范SQL注入式攻击代码：
<script language="javascript">
<!--
var url =
location.search;
var
re=/^\?(.*)(select%20|insert%20|delete%20from%20|count\(|drop%20table|update%20truncate%20|asc\(|mid\(|char\(|xp_cmdshell|exec%20master|net%20localgroup%20administrators|\"|:|net%20user|\|%20or%20)(.*)$/gi;
var
e = re.test(url);
if(e) {
alert("地址中含有非法字符～");
location.href="error.asp";
}
//-->
<script>
asp版的防范SQL注入式攻击代码～：
[CODE START]
<%
On Error Resume Next
Dim strTemp
If LCase(Request.ServerVariables("HTTPS")) = "off" Then
strTemp =
"http://"
Else
strTemp = "https://"
End If
strTemp = strTemp & Request.ServerVariables("SERVER_NAME")
If
Request.ServerVariables("SERVER_PORT") <> 80 Then strTemp = strTemp &
":" & Request.ServerVariables("SERVER_PORT")
strTemp = strTemp & Request.ServerVariables("URL")
If
Trim(Request.QueryString) <> "" Then strTemp = strTemp & "?" &
Trim(Request.QueryString)
strTemp = LCase(strTemp)
If Instr(strTemp,"select%20") or
Instr(strTemp,"insert%20") or Instr(strTemp,"delete%20from") or
Instr(strTemp,"count(") or Instr(strTemp,"drop%20table") or
Instr(strTemp,"update%20") or Instr(strTemp,"truncate%20") or
Instr(strTemp,"asc(") or Instr(strTemp,"mid(") or Instr(strTemp,"char(") or
Instr(strTemp,"xp_cmdshell") or Instr(strTemp,"exec%20master") or
Instr(strTemp,"net%20localgroup%20administrators") or Instr(strTemp,":") or
Instr(strTemp,"net%20user") or Instr(strTemp,"") or Instr(strTemp,"%20or%20")
then
Response.Write "<script language=javascript>"
Response.Write
"alert(非法地址！！);"
Response.Write "location.href=error.asp;"
Response.Write
"<script>"
End If
%>
[CODE END]
C# 检查字符串,防SQL注入攻击
这个例子里暂定为=号和号
bool
CheckParams(params object[] args)
{
string[]
Lawlesses={"=",""};
if(Lawlesses==null||Lawlesses.Length<=0)return
true;
//构造正则表达式,例:Lawlesses是=号和号,则正则表达式为 .*[=}].*
(正则表达式相关内容请见MSDN)
//另外,由于我是想做通用而且容易修改的函数,所以多了一步由字符数组到正则表达式,实际使用中,直接写正则表达式亦可;
string str_Regex=".*[";
for(int i=0;i<
Lawlesses.Length-1;i++)
str_Regex+=Lawlesses[i]+"|";
str_Regex+=Lawlesses[Lawlesses.Length-1]+"].*";
//
foreach(object arg in args)
{
if(arg is
string)//如果是字符串,直接检查
{
if(Regex.Matches(arg.ToString(),str_Regex).Count>0)
return
false;
}
else if(arg is
ICollection)//如果是一个集合,则检查集合内元素是否字符串,是字符串,就进行检查
{
foreach(object obj in (ICollection)arg)
{
if(obj is string)
{
if(Regex.Matches(obj.ToString(),str_Regex).Count>0)
return false;
}
}
}
}
return true;
以下是较为简单的防范方法，这些都是大家比较熟悉的方法，我就是转帖过来。希望能给你一点帮助~
主要是针对数字型的变量传递：
id = Request.QueryString("id")
If Not(isNumeric(id)) Then
Response.Write "非法地址~"
Response.End
End If
以下是正常显示代码~
如何再编码的过程中防范SQL注入式攻击
1、什么是SQL注入式攻击我
们知道Microsoft的SQL
Server数据库是支持一次数据库查询执行多条SQL语句的，比如说再查询管理器里面，我们可以输入一条SQL语句
select * from table1
select * from
table2
假如所选择的数据库中确实存在table1和table2的话，那么这个SQL语句就能够执行成功，并且能够返回正确的结果。同时，我们知道现在很多系统或者发布在Internet上的网站，管理员为了方便，一般都是直接采用sa的身份来连接数据库的，那么SQL注入式攻击主要就是抓住了系统在这么两个方面的弱点，攻击者把SQL语句插入到web表单输入，或者页面的查询字符串中，从而欺骗服务器执行恶意的SQL命令，以达到攻击的目的。
2.
注入式攻击的详细解释SQL下面我们将以一个简单的用户登陆为例，结合代码详细解释一下SQL注入式攻击，与及他的防范措施。对于一个简单的用户登陆可能的代码如下：
try
{
string
strUserName = this.txtUserName.Text;
string strPwd =
this.txtPwd.Text;
string strSql = "select * from userinfo where UserName='"
+ strUserName + "' and Password='" + strPwd + "'";
SqlConnection objDbConn =
new SqlConnection("数据库连接字符串");
SqlDataAdapter objAdapter = new
SqlDataAdapter(strSql,objDbConn);
DataSet objDataSet =
null;
objAdapter.Fill(objDataSet);//TODO 对获取的数据进行判断。
}
catch
(System.Exception e)
{
this.lblMsg.Text =
e.Message;
this.lblMsg.Visible =
true;
}
在上面这段代码中，如果用户的输入是正常的用户名和密码的话，那么执行都会比较正常，但是，假如输入用户名的时候，输入的是“johny’--”的话，在
SQLServer里面执行的语句将会是“select * from userinfo where UserName=’johny’--‘ and
Password=’密码’”，只要数据库中存在johny这个用户的话，那么不管密码是什么，语句都能够执行成功，并且能够顺利通过登陆。还
有更加厉害的，我们知道SQLServer里面有一些系统的存储过程，能够执行操作系统的很多命令，比如xp_cmdshell，假如上面用户登陆的时
候，用户名部分输入的是“johny’ exec xp_cmdshell ‘format
d:/s’--”，大家想想一下后果是什么？有恶意的用户，只要把’format d:/s’这个命令稍加改造就能够做很多不合法的事情啦。
3.
如何防范SQL注入式攻击既然我们解释了为什么会产生SQL的注入式攻击，那么我们接下来说说如何来防范这种情况的发生，解决的办法有很多，我们逐个介绍一下。
a)
在进行系统部署的时候，不要采用sa来连接数据库，在数据库中新建一个帐号，对这个帐号的权限进行限制，只允许在指定的数据库里面执行一下添加，修改的权限，这样我们就可以很好地防止通过执行xp_cmdshell来攻击服务器了。
b)
采用用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。在这里大家可能会说，我只是要执行一个简单的查询，难道也要写成一个存储过程吗，这样是不是太麻烦了，其实没有关系，我们只要采用ado.net里面的SqlParameter把上面的代码稍加改造，如下
try
{
string
strUserName = this.txtUserName.Text;
string strPwd =
this.txtPwd.Text;
string strSql = "select * from userinfo where UserName=@UserName and Password=@Password";
SqlConnection
objDbConn = new SqlConnection("数据库连接字符串");
SqlDataAdapter
objAdapter = new
SqlDataAdapter(strSql,objDbConn);
objAdapter.SelectCommand.Parameters.Add("@UserName",strUserName);
objAdapter.SelectCommand.Parameters.Add("@Password",strPwd);
DataSet
objDataSet = null;
objAdapter.Fill(objDataSet); //TODO
对获取的数据进行判断。
}
catch (System.Exception e)
{
this.lblMsg.Text =
e.Message;
this.lblMsg.Visible = true;
}
上面的这段代码，我们就可以比较好地防范SQL
注入式攻击了，原因是SQLServer里面存在一个sp_executesql的系统存储过程，ado里面只要sql语句中用到了
SqlParameter的方式的话，那么sql语句将会通过sp_executesql来执行，具体的情况大家可以用SQL
Server里面的Profile来进行跟踪一下，就非常清楚了。通过这种方法，我们就即可以不用写存储过程，有能够很好地防范SQL注入式攻击了对用户的输入进行校验，将用户输入里面存在的单引号进行转义（一个单引号替换成两个单引号），并且过滤里面存在的注释符，与及特殊命令。
