由于公司网站流量巨大，上次被一无名黑客来探了探路，留下“××到此一游”，虽然没有酿成恶果，但也把Leader吓出一身冷汗。下面是我昨晚写的的关于URL防SQL注入，先贴为敬。
/// <summary>
/// 检测是否含有危险字符（防止Sql注入）
/// </summary>
/// <param name="contents">预检测的内容</param>
/// <returns>返回True或false</returns>
private bool HasDangerousContents(string contents)
{
bool bReturnValue = false;
if (contents.Length > 0)
{
//convert to lower
string sLowerStr = contents.ToLower();
//RegularExpressions
string sRxStr = @"(\sand\s)|(\sand\s)|(\slike\s)|(select\s)|(insert\s)|(delete\s)|(update\s[\s\S].*\sset)|(create\s)|(\stable)|(<[iframe|/iframe|script|/script])|(')|(\sexec)|(\sdeclare)|(\struncate)|(\smaster)|(\sbackup)|(\smid)|(\scount)";
//Match
bool bIsMatch = false;
System.Text.RegularExpressions.Regex sRx = new System.Text.RegularExpressions.Regex(sRxStr);
bIsMatch = sRx.IsMatch(sLowerStr, 0);
if (bIsMatch)
{
bReturnValue = true;
}
}
return bReturnValue;
}
/// <summary>
/// 检测是否含有危险字符（防止Sql注入）
/// </summary>
/// <param name="contents">预检测的内容</param>
/// <returns>返回True或false</returns>
private bool HasDangerousContents(string contents)
{
bool bReturnValue = false;
if (contents.Length > 0)
{
//convert to lower
string sLowerStr = contents.ToLower();
//RegularExpressions
string sRxStr = @"(\sand\s)|(\sand\s)|(\slike\s)|(select\s)|(insert\s)|(delete\s)|(update\s[\s\S].*\sset)|(create\s)|(\stable)|(<[iframe|/iframe|script|/script])|(')|(\sexec)|(\sdeclare)|(\struncate)|(\smaster)|(\sbackup)|(\smid)|(\scount)";
//Match
bool bIsMatch = false;
System.Text.RegularExpressions.Regex sRx = new System.Text.RegularExpressions.Regex(sRxStr);
bIsMatch = sRx.IsMatch(sLowerStr, 0);
if (bIsMatch)
{
bReturnValue = true;
}
}
return bReturnValue;
}
使用存储过程和密码加密。
你这样也排除太多了
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();
学习ing...
問題網頁：http://topic.csdn.net/u/20080502/14/686618a2-7e12-4639-acc4-3bf659914569.html?t=ffqdxjlx
到以下几点 (人个认为)1、把所有 TextBox (Input type="text" ) 等输入信息的地方,限制一个最大输入长度。
这样至少可以给输入危险字符带来限制，这还是有点作用的，况且这样做并不难。(JavaScript遍历)2、楼主也提到过，URL可能也会传输入危险字符。这个解决，你可以用URL重写功能,这样比较好，至少可以增加难度
例如：abc.aspx?year=2008&month=5 可重写为 abc/2008/5 (扩展名是可以隐藏的)3、把你写的过滤方法及一些防范措施，最好用到 Global 或 http请求 里. (建议Global)这样应该比较不错。
还有，我想随便问一下楼主，你确认无名的黑客就是SQL注入攻击您的网站的？
或者说你的服务器,本身就是他的一个肉机或别的什么?
其实防注入还是很简单的!
SQL很容易造成SQL注入漏洞，想要一个安全的数据，就要防！
1、即使使用了RegexOptions.Compile选项，正则表达式的性能也不很理想，尤其是在楼主“流量巨大”的网站中很可能会造成性能瓶颈。
2、过滤的范围很难把握，不是过宽就是过窄。对楼主的这个例子来说，我的文章中有一个" and "都会被判断为危险字符串；另一方面，这个表达式对"exec"开头的字符串却无能为力。当然如果楼主的这个表达式可以只是针对某一个或几个参数进行验证，这样却必须保证对所有其他的输入参数都写对应的表达式来过滤。可以使用的方案主要有：
1、使用SqlParameter类
2、在数据库上增加一个抽象层次，防止直接对数据库的操作
3、在数据库方面，应用程序使用专门的帐户，设置其对应的权限，一定不要用管理员
4、避免拼接字符串
1、用SQL参数（参数在Command Text或者存储过程都可以用），不要用加串方式执行
2、合理设置数据库权限，严禁使用sa账号执行商务逻辑，应用程序所使用的数据库帐号权限应当最小化（程序不需要用到的权限一律不给，用不到的表不给访问权，只需要读数据的表不给写权限，等等），这样可以做到及时不幸被SQL注入，亦可以尽量减少损失
sa基本是开发测阶段使用的。
例如：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 //变量替换这种方式的字符串并接就不会有SQL注入的问题。
{
return sql.Replace("'", "").Replace("-", "").Replace("/*", "").Replace("*/", "").Replace("delete", "").Replace("drop", "").Replace("update", "");
}以前看到过一个
这个好，讲的几点都很实在，也实用^_^ 回答你的问题：
你确认无名的黑客就是SQL注入攻击您的网站的？ ”
对于这个问题，哈哈。本帖旨在对SQL防注入做一个深入讨论，最后作个总结，大家以后在SQL防注入上就不需要再花太多时间了。你想到的可能需要再开个帖：如果让你的服务器远离肉鸡的命运！
oh,shit "其实防注入还是很简单的！”
看来又来一狂人。不过这位兄弟提到的这个我觉得可取：“如有可能再建一个数据封装类来给数据传输加密”
三星的家伙，你的解决方案讲得很实在。
1.正则表达式的性能有待测试，尤其是在流量较大的网站中影响可能更加明显。 但仁兄的第二点我有话要说：
过滤的范围我觉得可以尽量可以考虑周到，使其不误判或漏判这一点完全可以人为做到。至于我写的这个例子， 有一个" and "确实是会被判断为危险字符串，因为我说了“这是作为URL提交检测的检测函数";还有一个。对于"exec"开头的字符串，也并非像仁兄说的无能为力，不知道你有没有看到这个“(\sexec)”。不过。你讲的第一点很值得研究。
这个是我的规则
就不用去担心会被注入
这丫讲的两点都实在，可以直接用。哈哈不过这句“楼主，难道防止SQL注入还要100种不同的方法吗？大家的回答足够了。”不太够意思。不是我想要多少种不同的方法。
我只要一种就够了，一个成熟的解决方案就够了。并且，不是我要。大家都要。