这些天,CSDN上讨论SQL注入攻击似乎是如火如荼啊...我也来参合一下..如下,CheckParams函数,接收参数任意,如参数中有字符串,则对字符串进行检查,如参数中有集合(如Array之类,总之是实现了ICollection的),则对集合中的字符串元素进行检查.大家可根据具体情况来定要过滤的字符,我这个例子里暂定为=号和'号,实际上我个人认为,过滤了这两个,似乎要进行SQL注入就已经比较困难了,当然,我对SQL是菜鸟,欢迎高手指正,谢谢.我的邮箱(MSN): Appledotnet@hotmail.com
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;}
NET防SQL注入(转) 
防止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文件中，在下面增加一个标签：如下
其中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.Split('-')[0];
String parameterType = safeParameters.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");
}
}
以后需要修改的时候我们只需要修改以上三个文件，对整个系统的维护将会大大提高效率，当然你可以根据自己的需要增加其它的变量参数和数据类型。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1764134
asp.net防SQL注入的安全措施 
一、什么是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，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。