以下是小编整理的网站安全：整站防止SQL注入式入侵（共含9篇），欢迎阅读分享，希望对大家有帮助。同时，但愿您也能像本文投稿人“爱护直觉”一样，积极向本站投稿分享好文章。
老邪的博客
SQL注入，通常一个一个文件修改不仅麻烦而且还有漏掉的危险，下面我说一下如何从整个系统防止注入，
做到以下三步，相信你的程序就会比较安全了，而且对整个网站的维护也将变的简单。
一、数据验证类
parameterCheck.cs
public class parameterCheck{
public static bool isEmail(string emailString){
return System.Text.RegularExpressions.Regex.IsMatch(emailString, “[’\\w_-]+(\\.
[’\\w_-]+)*@[’\\w_-]+(\\.[’\\w_-]+)*\\.[a-zA-Z]{2,4}”);
}
public static bool isInt(string intString){
return System.Text.RegularExpressions.Regex.IsMatch(intString ,“^(\\d{5}-\\d{4})|
(\\d{5})$”);
}
public static bool isUSZip(string zipString){
return System.Text.RegularExpressions.Regex.IsMatch(zipString ,“^-[0-9]+$|^[0-9]
+$”);
}
}二、Web.config
在你的Web.config文件中，在下面增加一个标签，如下：
USzip“ />
其中key是后面的值为“OrderId-int32”等，其中“-”前面表示参数的名称比如：OrderId，后面的int32表示数据类型。
三、Global.asax
在Global.asax中增加下面一段：
protected void Application_BeginRequest(Object sender, EVEntArgs e){
String[] safeParameters = System.Configuration.ConfigurationSettings.AppSettings
[”safeParameters“].ToString.Split(’,’);
for(int i= 0 ;i < safeParameters.Length; i++){
String parameterName = safeParameters[i].Split(’-’)[0];
String parameterType = safeParameters[i].Split(’-’)[1];
isValidParameter(parameterName, parameterType);
}
}
public void isValidParameter(string parameterName, string parameterType){
string parameterValue = Request.QueryString[parameterName];
if(parameterValue == null) return;
if(parameterType.Equals(”int32“)){
if(!parameterCheck.isInt(parameterValue)) Response.Redirect(”parameterError.aspx“);
}
else if (parameterType.Equals(”double“)){
if(!parameterCheck.isDouble(parameterValue)) Response.Redirect(”parameterError.aspx“);
}
else if (parameterType.Equals(”USzip“)){
if(!parameterCheck.isUSZip(parameterValue)) Response.Redirect(”parameterError.aspx“);
}
else if (parameterType.Equals(”email“)){
if(!parameterCheck.isEmail(parameterValue)) Response.Redirect(”parameterError.aspx“);
}
}以后需要修改的时候我们只需要修改以上三个文件，对整个系统的维护将会大大提高效率，当然你可以根据自己的需要增加其它的变量参数和数据类型，
防止SQL注入，通常一个一个文件修改不仅麻烦而且还有漏掉的危险，下面我说一下如何从整个系统防止注入，
做到以下三步，相信你的程序就会比较安全了，而且对整个网站的维护也将变的简单。
一、数据验证类
parameterCheck.cs
public class parameterCheck{
public static bool isEmail(string emailString){
return System.Text.RegularExpressions.Regex.IsMatch(emailString, ”[\w_-]+(\.
[\w_-]+)*@[\w_-]+(\.[\w_-]+)*\.[a-zA-Z]{2,4}“);
}
public static bool isInt(string intString){
return System.Text.RegularExpressions.Regex.IsMatch(intString ,”^(\d{5}-\d{4})|
(\d{5})$“);
}
public static bool isUSZip(string zipString){
return System.Text.RegularExpressions.Regex.IsMatch(zipString ,”^-[0-9]+$|^[0-9]
+$“);
}
}
二、Web.config
在你的Web.config文件中，在下面增加一个标签，如下：
USzip” />
其中key是后面的值为“OrderId-int32”等，其中“-”前面表示参数的名称比如：OrderId，后面的int32表示数据类型。
三、Global.asax
在Global.asax中增加下面一段：
protected void Application_BeginRequest(Object sender, EventArgs e){
String[] safeParameters = System.Configuration.ConfigurationSettings.AppSettings
[“safeParameters”].ToString().Split(,);
for(int i= 0 ;i < safeParameters.Length; i++){
String parameterName = safeParameters[i].Split(-)[0];
String parameterType = safeParameters[i].Split(-)[1];
isValidParameter(parameterName, parameterType);
}
}
public void isValidParameter(string parameterName, string parameterType){
string parameterValue = Request.QueryString[parameterName];
if(parameterValue == null) return;
if(parameterType.Equals(“int32”)){
if(!parameterCheck.isInt(parameterValue)) Response.Redirect(“parameterError.aspx”);
}
else if (parameterType.Equals(“double”)){
if(!parameterCheck.isDouble(parameterValue)) Response.Redirect(“parameterError.aspx”);
}
else if (parameterType.Equals(“USzip”)){
if(!parameterCheck.isUSZip(parameterValue)) Response.Redirect(“parameterError.aspx”);
}
else if (parameterType.Equals(“email”)){
if(!parameterCheck.isEmail(parameterValue)) Response.Redirect(“parameterError.aspx”);
}
}
以后需要修改的时候我们只需要修改以上三个文件，对整个系统的维护将会大大提高效率，当然你可以根据自己的需要增加其它的变量参数和数据类型，
网站后台验证相当重要，特别是一些网站后台权限很大的网站，如果你拿到一个网站的后台管理员帐号，基本上已经拿下这个网站，然后通过上传木马什么的拿到服务器权限。
一提到绕过后台登陆验证直接进入网站后台管理系统，想必大家都能想到经典的万能密码：or =or 吧
or =or 原理
我们都知道后台登陆验证一般的方式都是 将用户在登录口输入的账号密码拿去与数据库中的记录做验证，并且要求输入的账号密码要等于数据库中某条记录的账号密码，验证通过则程序就会给用户一个 sssion，然后进入后台，否则就返回到登陆口。而对于or =or 漏洞，我们先来看以下代码：
<%
pwd = request.form(“pwd”) 获取用户输入的密码,再把值赋给pwd
name = request.form(“name”) 获取用户输入的用户名再把值赋给name
都没有进行任何过滤
Set rs = Server.Createob ject(“ADODB.Connection”)
sql = “select * from Manage_User where UserName=” & name & “ And PassWord=”&encrypt(pwd)&“” 将用户名和密码放入查询语句中查询数据库，
Set rs = conn.Execute(sql) 执行SQL语句，执行后并得到rs对象结果，“真”或“假”
If Not rs.EOF = True Then 如果是真则执行以下代码
Session(“Name”) = rs(“UserName”) 将UserName的属性赋给Name的Session自定义变量
Session(“pwd”) = rs(“PassWord”) 将PassWord的属性赋给pwd的Session自定义变量
Response.Redirect(“Manage.asp”)了 利用Response对象的Redirect方法重定向Manage.asp
Else 否则执行以下代码
Response.Redirect “Loginsb.asp?msg=您输入了错误的帐号或口令，请再次输入!”
End If
%>
针对以上例子我们只需要在用户名处提交or =or ，这样就使得SQL语句变成：select * from Manage_User where UserName=’or ‘=or And PassWord=123456。执行后得到rs对象的结果为真，这样就能顺利的进入后台了。
现在的目的就是使
sql = “select * from Manage_User where UserName=” & name & “ And PassWord=”&encrypt(pwd)&“”
这条语句执行为真，要达到这个目的就要用到我们的or 登陆，只要我们构造一个特殊的用户名，就可以绕过程序的验证，直接达到后台。之所以有or 登陆就是因为前面的用户名过滤不严格导致的。在上面的后台登陆代码中我们只要在用户名处输入1′ or 1=1 or ‘1′=’1，密码处我输入123，其实随便输入什么符号都可以，点击登陆就进入后台了。
上面输入的数据达到我们服务器后就要执行SQL查询语句了，这个时候那条SQL查询语句就变成了：sql = “select * from Manage_User where UserName=‘” 1′ or 1=1 or ‘1′=’1′and password=’123′”，
注意，第一个单引号是为了跟UserName=‘后的单引号闭合从而构造or 运算，这样跟name配对的单引号还需一个单引号才能闭合，所以有了‘1‘=‘1。这就相当于将name=‘‘变成了name=‘ 1‘or ‘1‘=‘1 ‘。
所以我们在用户名处输入’1′ or 1=1 or ‘1′=’1′，密码输入任何字符之后，我们的SQL查询语句的结果为真了。
SQL注入防范方法
为了避免出现这个漏洞，现在基本上的后台验证都不会使用这类方式，而是取得用户输入的账号和密码，在SQL中先将用户名与数据库中的记录做对比，若 数据库中某条记录的用户名等于用户输入的用户名，则取出该条记录中的密码，然后再与用户输入的密码对比，正确就通过，不正确就返回。例如
<%
pwd = request.form(“pwd”) 获取用户输入的密码,再把值赋给pwd
name = request.form(“name”) 获取用户输入的用户名再把值赋给name
都没有进行任何过滤
Set rs = Server.Createob ject(“ADODB.Connection”)
sql = “select * from Manage_User where UserName=” & name & “” 将用户名和密码放入查询语句中查询数据库，
Set rs = conn.Execute(sql) 执行SQL语句，执行后并得到rs对象结果，“真”或“假”
If Not rs.EOF = True Then 如果是真则执行以下代码
password=rs(“password”) 取得密码数据
if password=md5(pwd) then
Session(“Name”) = rs(“UserName”) 将UserName的属性赋给Name的Session自定义变量
Session(“pwd”) = rs(“PassWord”) 将PassWord的属性赋给pwd的Session自定义变量
Response.Redirect(“Manage.asp”)了 利用Response对象的Redirect方法重定向Manage.asp
else
response.write “密码错误!!!!”
end if
Else 否则执行以下代码
Response.Redirect “Loginsb.asp?msg=您输入了错误的帐号或口令，请再次输入!”
End If
%>
通过以上例子可知道，密码的验证不再是直接在SQL语句中做验证了，而是根据用户名，取出对应的密码，然后再与用户输入的做对比。这样一来就造成了 我们不能使用or =or 绕过了。有的朋友在这里可能有疑问了，若我们提交or =or 那么SQL语句就变成：
select * from Manage_User where UserName=or =or ，
这样一来得到的结果也应该是真啊，为什么就不能绕过呢?
其实就算SQL查询的地方得到的值是真，可别忘了后面还有密码的验证，若我们提交以上SQL，得到账号是真的，那么后面根据账号去数据库中取出来的密码与用户提交的密码是绝对通不过的。
好了，对于or =or 漏洞的分析先就暂且说到这里，以上的均为我个人对该漏洞的理解，并不代表就是完全正确的，若有不当的地方还望大家多多指教。
防御SQL注入有妙法
第一步：很多新手从网上下载SQL通用防注入系统的程序，在需要防范注入的页面头部用来防止别人进行手动注入测试，
如何防止sql注入攻击网站
。可是如果通过SQL注入分析器就可轻松跳过防注入系统并自动分析其注入点。然后只需要几分钟，你的管理员账号及密码就会被分析出来。第二步：对于注入分析器的防范，笔者通过实验，发现了一种简单有效的防范方法。首先我们要知道SQL注入分析器是如何工作的。在操作过程中，发现软件并不是冲着“admin”管理员账号去的，而是冲着权限（如flag=1）去的。这样一来，无论你的管理员账号怎么变都无法逃过检测。
第三步：既然无法逃过检测，那我们就做两个账号，一个是普通的管理员账号，一个是防止注入的账号，为什么这么说呢？笔者想，如果找一个权限最大的账号制造假象，吸引软件的检测，而这个账号里的内容是大于千字以上的中文字符，就会迫使软件对这个账号进行分析的时候进入全负荷状态甚至资源耗尽而死机，下面我们就来修改数据库吧。
1.对表结构进行修改。将管理员的账号字段的数据类型进行修改，文本型改成最大字段255（其实也够了，如果还想做得再大点，可以选择备注型），密码的字段也进行相同设置。
2.对表进行修改。设置管理员权限的账号放在ID1，并输入大量中文字符（最好大于100个字）。
3.把真正的管理员密码放在ID2后的任何一个位置（如放在ID549上）。
我们通过上面的三步完成了对数据库的修改。
这时是不是修改结束了呢？其实不然，要明白你做的ID1账号其实也是真正有权限的账号，现在计算机处理速度那么快，要是遇上个一定要将它算出来的软件，这也是不安全的。我想这时大多数人已经想到了办法，对，只要在管理员登录的页面文件中写入字符限制就行了！就算对方使用这个有上千字符的账号密码也会被挡住的，而真正的密码则可以不受限制。
style=“display:block;padding:0px 10px;” class=“ContentFont”>
代码一:
<%
'--------定义部份------------------
Dim Fy_Post,Fy_Get,Fy_In,Fy_Inf,Fy_Xh,Fy_db,Fy_dbstr
'自定义需要过滤的字串,用 “防 ” 分隔
Fy_In = “’’’’防;防and防exec防insert防select防delete防update防count防*防%防chr防mid防master防 truncate防char防declare防 <防>防=防 |防-防_ ”
Fy_Inf = split(Fy_In, “防 ”)
If Request.Form. < >“ ” Then
For Each Fy_Post In Request.Form
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh)) < >0 Then
Response.Write “
代码一:
<%
'--------定义部份------------------
Dim Fy_Post,Fy_Get,Fy_In,Fy_Inf,Fy_Xh,Fy_db,Fy_dbstr
'自定义需要过滤的字串,用 ”防 “ 分隔
Fy_In = ”’’’’防;防and防exec防insert防select防delete防update防count防*防%防chr防mid防master防 truncate防char防declare防 <防>防=防 |防-防_ “
Fy_Inf = split(Fy_In, ”防 “)
If Request.Form. < >” “ Then
For Each Fy_Post In Request.Form
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh)) < >0 Then
Response.Write ”
Response.Write “非法操作！本站已经给大侠您做了如下记录↓
”
Response.Write “操作IP： ”&Request.ServerVariables( “REMOTE_ADDR ”)& “
”
Response.Write “操作时间： ”&Now& “
”
Response.Write “操作页面： ”&Request.ServerVariables( “URL ”)& “
”
Response.Write “提交方式：POST
”
Response.Write “提交参数： ”&Fy_Post& “
”
Response.Write “提交数据： ”&Request.Form(Fy_Post)
Response.End
End If
Next
Next
End If
If Request.QueryString < >“ ” Then
For Each Fy_Get In Request.QueryString
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.QueryString(Fy_Get)),Fy_Inf(Fy_Xh)) < >0 Then
Response.Write “
Response.Write ”非法操作！本站已经给大侠您做了如下记录↓
“
Response.Write ”操作IP： “&Request.ServerVariables( ”REMOTE_ADDR “)& ”
“
Response.Write ”操作时间： “&Now& ”
“
Response.Write ”操作页面： “&Request.ServerVariables( ”URL “)& ”
“
Response.Write ”提交方式：GET
“
Response.Write ”提交参数： “&Fy_Get& ”
“
Response.Write ”提交数据： “&Request.QueryString(Fy_Get)
Response.End
End If
Next
Next
End If
% >
过滤网址的非法字符串
试试这两种方法:
第一种：
squery=lcase(Request.ServerVariables(”QUERY_STRING“))
sURL=lcase(Request.ServerVariables(”HTTP_HOST“))
SQL_injdata =”:|;|>|<|--|sp_|xp_|\|dir|cmd|^|(|)|+|$|'|copy|format|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare“
SQL_inj = split(SQL_Injdata,”|“)
For SQL_Data=0 To Ubound(SQL_inj)
if instr(squery&sURL,Sql_Inj(Sql_DATA))>0 Then
Response.Write ”SQL通用防注入系统“
Response.end
end if
next
第二种：
SQL_injdata =”:|;|>|<|--|sp_|xp_|\|dir|cmd|^|(|)|+|$|'|copy|format|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare“
SQL_inj = split(SQL_Injdata,”|“)
If Request.QueryString”“ Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 Then
Response.Write ”SQL通用防注入系统“
Response.end
end if
next
Next
End If
If Request.Form”“ Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write ”SQL通用防注入系统“
Response.end
end if
next
next
end if
第三种
<%
'--------定义部份------------------
Dim Str_Post,Str_Get,Str_In,Str_Inf,Str_Xh,Str_db,Str_dbstr
'自定义需要过滤的字串,用 ”■“分离
Str_In = ”'■;■and■exec■insert■select■delete■update■count■*■%■chr■mid■master■truncate■char■declare“
'----------------------------------
%>
<%
Str_Inf = split(Str_In,”■“)
'--------POST部份------------------
If Request.Form”“ Then
For Each Str_Post In Request.Form
For Str_Xh=0 To Ubound(Str_Inf)
If Instr(LCase(Request.Form(Str_Post)),Str_Inf(Str_Xh))0 Then
'--------写入数据库----------头-----
Str_dbstr=”DBQ=“+server.mappath(”SqlIn.mdb“)+”;DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};“
Set Str_db=Server.CreateObject(”ADODB.CONNECTION“)
Str_db.open Str_dbstr
Str_db.Execute(”insert into SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) values('“&Request.ServerVariables(”REMOTE_ADDR“)&”','“&Request.ServerVariables(”URL“)&”','POST','“&Str_Post&”','“&replace(Request.Form(Str_Post),”'“,”''“)&”')“)
Str_db.close
Set Str_db = Nothing
'--------写入数据库----------尾-----
Response.Write ”“
Response.Write ”非法操作！系统做了如下记录:
“
Response.Write ”操作IP：“&Request.ServerVariables(”REMOTE_ADDR“)&”
“
Response.Write ”操作时间：“&Now&”
“
Response.Write ”操作页面：“&Request.ServerVariables(”URL“)&”
“
Response.Write ”提交方式：POST
“
Response.Write ”提交参数：“&Str_Post&”
“
Response.Write ”提交数据：“&Request.Form(Str_Post)
Response.End
End If
Next
Next
End If
'----------------------------------
'--------GET部份-------------------
If Request.QueryString”“ Then
For Each Str_Get In Request.QueryString
For Str_Xh=0 To Ubound(Str_Inf)
If Instr(LCase(Request.QueryString(Str_Get)),Str_Inf(Str_Xh))0 Then
'--------写入数据库----------头-----
Str_dbstr=”DBQ=“+server.mappath(”SqlIn.mdb“)+”;DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};“
Set Str_db=Server.CreateObject(”ADODB.CONNECTION“)
Str_db.open Str_dbstr
Str_db.Execute(”insert into SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) values('“&Request.ServerVariables(”REMOTE_ADDR“)&”','“&Request.ServerVariables(”URL“)&”','GET','“&Str_Get&”','“&replace(Request.QueryString(Str_Get),”'“,”''“)&”')“)
Str_db.close
Set Str_db = Nothing
'--------写入数据库----------尾-----
Response.Write ”“
Response.Write ”非法操作！系统做了如下记录:
“
Response.Write ”操作IP：“&Request.ServerVariables(”REMOTE_ADDR“)&”
“
Response.Write ”操作时间：“&Now&”
“
Response.Write ”操作页面：“&Request.ServerVariables(”URL“)&”
“
Response.Write ”提交方式：GET
“
Response.Write ”提交参数：“&Str_Get&”
“
Response.Write ”提交数据：“&Request.QueryString(Str_Get)
Response.End
End If
Next
Next
End If
%>
很多人都知道SQL注入，也知道SQL参数化查询可以防止SQL注入，可为什么能防止注入却并不是很多人都知道的，
本文主要讲述的是这个问题，也许你在部分文章中看到过这块内容，当然了看看也无妨。
首先：我们要了解SQL收到一个指令后所做的事情：
具体细节可以查看文章：Sql Server 编译、重编译与执行计划重用原理
在这里，我简单的表示为： 收到指令 ->编译SQL生成执行计划 ->选择执行计划 ->执行执行计划。
具体可能有点不一样，但大致的步骤如上所示。
接着我们来分析为什么拼接SQL 字符串会导致SQL注入的风险呢？
首先创建一张表Users:
CREATE TABLE [dbo].[Users]([Id] [uniqueidentifier] NOT NULL,[UserId] [int] NOT NULL,[UserName] [varchar](50) NULL,[Password] [varchar](50) NOT NULL,CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED([Id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY]
插入一些数据：
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID,1,'name1','pwd1');INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),2,'name2','pwd2');INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),3,'name3','pwd3');INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),4,'name4','pwd4');INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),5,'name5','pwd5');
假设我们有个用户登录的页面，代码如下：
验证用户登录的sql 如下：
select COUNT(*) from Users where Password = 'a' and UserName = 'b'
这段代码返回Password 和UserName都匹配的用户数量，如果大于1的话，那么就代表用户存在。
本文不讨论SQL 中的密码策略，也不讨论代码规范，主要是讲为什么能够防止SQL注入
，请一些同学不要纠结与某些代码，或者和SQL注入无关的主题。可以看到执行结果：
这个是SQL profile 跟踪的SQL 语句。
注入的代码如下：
select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'
这里有人将UserName设置为了 “b' or 1=1 –”.
实际执行的SQL就变成了如下：
可以很明显的看到SQL注入成功了。
很多人都知道参数化查询可以避免上面出现的注入问题，比如下面的代码：
class Program{private static string connectionString = ”Data Source=.;Initial Catalog=Test;Integrated Security=True“;static void Main(string[] args){Login(”b“, ”a“);Login(”b' or 1=1--“, ”a“);}private static void Login(string userName, string password){using (SqlConnection conn = new SqlConnection(connectionString)){conn.Open();SqlCommand comm = new SqlCommand();comm.Connection = conn;//为每一条数据添加一个参数comm.CommandText = ”select COUNT(*) from Users where Password = @Password and UserName = @UserName“;comm.Parameters.AddRange(new SqlParameter[]{new SqlParameter(”@Password“, SqlDbType.VarChar) { Value = password},new SqlParameter(”@UserName“, SqlDbType.VarChar) { Value = userName},});comm.ExecuteNonQuery();}}}
实际执行的SQL 如下所示：
exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(1)',@Password='a',@UserName='b'exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(11)',@Password='a',@UserName='b'' or 1=1—'
可以看到参数化查询主要做了这些事情：
1：参数过滤，可以看到 @UserName='b'' or 1=1—'
2：执行计划重用
因为执行计划被重用，所以可以防止SQL注入，
首先分析SQL注入的本质，
用户写了一段SQL 用来表示查找密码是a的，用户名是b的所有用户的数量。
通过注入SQL，这段SQL现在表示的含义是查找(密码是a的，并且用户名是b的，) 或者1=1 的所有用户的数量。
可以看到SQL的语意发生了改变，为什么发生了改变呢？，因为没有重用以前的执行计划，因为对注入后的SQL语句重新进行了编译，因为重新执行了语法解析。所以要保证SQL语义不变，即我想要表达SQL就是我想表达的意思，不是别的注入后的意思，就应该重用执行计划。
如果不能够重用执行计划，那么就有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询就可能变化。
在SQL Server 中查询执行计划可以使用下面的脚本：
DBCC FreeProccacheselect total_elapsed_time / execution_count 平均时间,total_logical_reads/execution_count 逻辑读,usecounts 重用次数,SUBSTRING(d.text, (statement_start_offset/2) + 1,((CASE statement_end_offsetWHEN -1 THEN DATALENGTH(text)ELSE statement_end_offset END- statement_start_offset)/2) + 1) 语句执行 from sys.dm_exec_cached_plans across apply sys.dm_exec_query_plan(a.plan_handle) c,sys.dm_exec_query_stats bcross apply sys.dm_exec_sql_text(b.sql_handle) d--where a.plan_handle=b.plan_handle and total_logical_reads/execution_count>4000ORDER BY total_elapsed_time / execution_count DESC;
有篇文章： Sql Server参数化查询之where in和like实现详解在这篇文章中有这么一段：
这里作者有一句话：”不过这种写法和直接拼SQL执行没啥实质性的区别”
任何拼接SQL的方式都有SQL注入的风险，所以如果没有实质性的区别的话，那么使用exec 动态执行SQL是不能防止SQL注入的。
比如下面的代码：
private static void TestMethod(){using (SqlConnection conn = new SqlConnection(connectionString)){conn.Open();SqlCommand comm = new SqlCommand();comm.Connection = conn;//使用exec动态执行SQL//实际执行的查询计划为(@UserID varchar(max))select * from Users(nolock) where UserID in (1,2,3,4)//不是预期的(@UserID varchar(max))exec('select * from Users(nolock) where UserID in ('+@UserID+')')comm.CommandText = ”exec('select * from Users(nolock) where UserID in ('+@UserID+')')“;comm.Parameters.Add(new SqlParameter(”@UserID“, SqlDbType.VarChar, -1) { Value = ”1,2,3,4“ });//comm.Parameters.Add(new SqlParameter(”@UserID“, SqlDbType.VarChar, -1) { Value = ”1,2,3,4); delete from Users;--“ });comm.ExecuteNonQuery();}}
执行的SQL 如下：
exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4'
可以看到SQL语句并没有参数化查询。
如果你将UserID设置为”
1,2,3,4); delete from Users;—-
”,那么执行的SQL就是下面这样：
exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4); delete from Users;--'
不要以为加了个@UserID 就代表能够防止SQL注入，实际执行的SQL 如下：
任何动态的执行SQL 都有注入的风险，因为动态意味着不重用执行计划，而如果不重用执行计划的话，那么就基本上无法保证你写的SQL所表示的意思就是你要表达的意思。
这就好像小时候的填空题，查找密码是(____) 并且用户名是(____)的用户。
不管你填的是什么值，我所表达的就是这个意思。
最后再总结一句：因为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入,如果不能重用执行计划，就有可能出现SQL注入，存储过程也是一样的道理，因为可以重用执行计划。
原文链接：www.cnblogs.com/LoveJenny/archive//01/15/2860553.html
Sql注入式攻击，在 看来一般是用于攻击别人的网站或者程序，但现在我们可以转换一下思想，利用sql注入式为我们服务，
例如：有一个旧的程序，使用简单三层，这个程序操作的表名是Table1，Table1的字段有：id(int)，column1(nvarchar(50))，column2(nvarchar(50))，adddate(smalldatetime).其中adddate字段是后加上的，也就是有的数据元素中adddate字段有值，有的是null，在原程序中没有使用adddate字段的值，现在要求使用adddate以判断不同的年份，并且为空的值划分到老数据中（比如null和2013/9/26都属于的数据，/1/1的数据属于的数据），不允许更改数据库中的数据。
假设我们在DAL和BLL层中分别写一个可以只传入年份（比如，传入2013，形参名为year）的方法，在Web层中调用，
为了用sql注入式方法的思路写程序，我们不对传入的year做过多的逻辑判断，只是把year放入预写好的sql语句中执行（假设我们的查询sql语句很简单，比如：string sql = ”select * from Table1 where adddate >= ' “+year+” /1/1' and adddate <= ' “+year+” /12/31' “;），那么这种情景下取出来的20的数据是不包含时间为null的数据元素的。此时我们可以利用sql注入的方式，传year的值为“ ' or adddate is null and 1='1';-- ”，执行后查到的数据就是2013年的和为null的数据.
以上只是我想的一个简单的逆向想法：把原本用于黑别人的东西拿来放在程序中使用以达到正确目的。引深一点就是把原本是有害的东西不一定完全就是有害的（那只是放错了地方），在正确的地方使用会达到很好的效果。
本人是新手，高手勿喷。
近年来，SQL注入式攻击一直如幽灵般困扰着众多企业，成为令企业毛骨悚然的梦魇，从八月中旬以来，新一轮的大规模SQL注入式攻击袭掠了大量的网站，连苹果公司的网站也未能幸免。这种猖獗的攻击向业界招示其日渐流行的趋势， 们也越来越喜欢这种可以渗透进入企业的基础架构和数据库资源的攻击方式。
关于对付SQL注入攻击的方法已经有许多讨论，但是为什么还是有大量的网站不断地遭受其魔掌呢？安全研究人员认为，现在正是重新梳理最佳方法来对付大规模的SQL注入攻击的时候，从而减轻与注入攻击相关的风险。笔者在此介绍的这些方法未必是革命性的创举，但是又有多少企业真正按照要求全面地实施这些方法呢？
下面，我们将一一谈论这些方法：
使用参数化查询
企业应当制定并强化自行开发软件的安全编码指南，要求开发人员使用参数化查询来构建SQL查询，这样就可以将数据与代码区分开来。
对于多数SQL查询来说，开发人员需要指明某类标准，为此，就需要利用参数化查询，其实就是在运行时可传递的参数。参数化查询就是在SQL语句中有一个或多个嵌入参数的查询。这种将参数嵌入到SQL语句中的方法与动态构造SQL字符串相比，不易产生错误。下面我们看一个在.NET应用程序中使用参数化查询的例子。假设我们想给张三增加工资500元，可参考如下的代码。这些代码范例演示了参数化查询的使用，并展示了如何使用更新语句：
通过利用SQL的更新命令，你可以更新记录。在上面的例子中，我们作了如下操作：创建并打开一个数据库链接；创建一个代表执行更新语句的数据库命令；使用EDBCommand 的ExecuteNonQuery()方法执行插入命令。
每一个参数都用一个EDBParameter对象指明。对于需要在SQL语句中指定的每一个参数来说，你需要创建一个EDBParameter对象，然后将值指派给这个对象。然后，将EDBParameter对象添加到EDBCommand命令的参数集中。
对于多数开发平台来说，应当使用参数化的语句而不是将用户输入嵌入到语句中。在许多情况下，SQL语句是固定的，每一个参数都是一个标量，而不是一个表。用户输入会被指派给一个参数。下面再给出一个使用Java和JDBC API的例子：
PreparedStatement prep = conn.prepareStatement(”SELECT * FROM USERS WHERE USERNAME=？ AND PASSWORD=？")；
prep.setString(1， username)；
prep.setString(2， password)；
prep.executeQuery()；
笔者用这些例子只是想告诉开发人员，应当确保在查询数据库之前对输入进行净化，
要保障用户输入到网站的内容就是你正要查找的数据类型，所以说，如果你正在寻找一个数字，就要努力保障这种输入一定是一个数字而非字符。
实施过滤和监视工具
在Web应用程序和数据库这个水平上的过滤和监视工具可有助于阻止攻击并检测攻击行为，从而减轻暴露在大规模的SQL注入式攻击中的风险。
在应用程序水平上，企业应当通过实施运行时的安全监视来防御SQL注入攻击和生产系统中的漏洞。同样地，Web应用防火墙也有助于企业部署某些基于行为的规则集，可以在发生损害之前阻止攻击。
在数据库水平上，数据库活动监视还可以从后台过滤攻击。数据库的监视活动是对付SQL注入的一种很强大的工具。对于目前所知道的注入攻击而言，应当部署好过滤器，以便向数据库管理员发出警告：正在发生不太安全的问题；还要有一些一般的过滤器，用以查找SQL注入攻击中的典型伎俩，如破坏SQL代码的不规则的数字引用等。
精心编制错误消息
可以利用你的错误消息，以便于将来对付你。所以开发团队和数据库管理员都需要考虑：在用户输入某些出乎意料的“数据”时，应当返回的错误消息。
企业应当配置Web服务器和数据库服务器，使其不输出错误或警告消息。因为攻击者可以利用“盲目SQL注入”等技术来了解你的数据库设计细节。
及时打补丁并强化数据
由于没有打补丁或者配置错误，而造成与Web应用程序相关联的数据库遭受攻击，那么与SQL注入攻击相关的风险也会因之增加。
很显然，只要有补丁可用，你就需要给数据库打补丁，并且还要给Web应用程序和Web服务打补丁。
此外，别忘了你的数据库是怎样配置的。你需要禁用不必要的服务和功能，目的是为了强化数据库及其赖以运行的操作系统。
限制数据库的特权
最后，企业需要更好地管理与Web应用程序相关的账户与后台数据库交互的方式。许多问题之所以发生，其原因在于数据库管理员全面开放了一些账户，其目的是为了让开发人员更轻松地工作。但是，这些超级用户账户极易遭受攻击，并会极大地增加由SQL注入攻击及其它Web攻击给数据库所造成的风险。
一定要正确地管理所有的账户，使其仅能以最低的特权访问后台的数据库，当然前提是能够完成其工作。你一定要保障这些账户不会拥有对数据库作出更改的权利。
★ shopxp pinglun.asp文件SQL注入漏洞分析漏洞预警
