（狂散分！！2008年SQL防注入第一帖）SQL防注入解决方案大征集

cnzhouhai 2008-05-02 09:59:30

由于公司网站流量巨大，上次被一无名黑客来探了探路，留下“××到此一游”，虽然没有酿成恶果，但也把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;

        }

...全文

1246 109 打赏收藏转发到动态举报

写回复

用AI写文章

109 条回复

切换为时间正序

请发表友善的回复…

发表回复

fengxinghua428 2009-12-03

打赏
举报

防止sql注入的方式可以将存储过程写成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 //变量替换
这样写可定没问题

king__cai 2009-04-03

打赏
举报

看看学习了

golelsq 2008-07-28

打赏
举报

好贴，收藏了！！！

kofkyo 2008-06-11

打赏
举报

这个正则看起来不错，mark一下

industrial 2008-05-15

打赏
举报

mark

nghf102 2008-05-15

打赏
举报

收藏并学习....

cnzhouhai 2008-05-12

打赏
举报

仁兄说的极是~```````

fanruinet 2008-05-10

打赏
举报

[Quote=引用 85 楼 cnzhouhai 的回复:]
但仁兄的第二点我有话要说：
过滤的范围我觉得可以尽量可以考虑周到，使其不误判或漏判这一点完全可以人为做到。至于我写的这个例子，有一个" and "确实是会被判断为危险字符串，因为我说了“这是作为URL提交检测的检测函数";还有一个。对于"exec"开头的字符串，也并非像仁兄说的无能为力，不知道你有没有看到这个“(\sexec)”。 [/Quote]

\sexec只匹配exec前面带一个\s的字符串，"exec"开头的字符串不能被匹配，也许你的意思是\s*exec。这只是我发现的疏漏之一，黑客们还可能发现更多了以利用的漏洞

另外既然你的方案只能"这是作为URL提交检测的检测函数"，就是我的回复中的“过滤的范围很难把握”。因为SQL注入不是仅会发生在URL的字符串中，FORM POST的数据同样可以注入，但你的方案不能用在这里。就像我回复的帖子，如果CSDN处理不好的话同样会产生严重的后果，但是不能不让我在帖子里回复包含“and”等。

cnzhouhai 2008-05-05

打赏
举报

[Quote=引用 57 楼 fancyf 的回复:]
在解决SQL Injection的可行方案中，基于正则表达式的方案不予考虑，理由有：
1、即使使用了RegexOptions.Compile选项，正则表达式的性能也不很理想，尤其是在楼主“流量巨大”的网站中很可能会造成性能瓶颈。
2、过滤的范围很难把握，不是过宽就是过窄。对楼主的这个例子来说，我的文章中有一个" and "都会被判断为危险字符串；另一方面，这个表达式对"exec"开头的字符串却无能为力。当然如果楼主的这个表达式可以只是针对某…
[/Quote]

三星的家伙，你的解决方案讲得很实在。
1.正则表达式的性能有待测试，尤其是在流量较大的网站中影响可能更加明显。

但仁兄的第二点我有话要说：
过滤的范围我觉得可以尽量可以考虑周到，使其不误判或漏判这一点完全可以人为做到。至于我写的这个例子，有一个" and "确实是会被判断为危险字符串，因为我说了“这是作为URL提交检测的检测函数";还有一个。对于"exec"开头的字符串，也并非像仁兄说的无能为力，不知道你有没有看到这个“(\sexec)”。

不过。你讲的第一点很值得研究。

cnzhouhai 2008-05-05

打赏
举报

[Quote=引用 51 楼 w5325698 的回复:]
只要先在查询分析器里建好存储过程，我建议最好用视图至于里代码里吗，你多用适配器+SQL参数结合来使用,如有可能再建一个数据封装类来给数据传输加密.
其实防注入还是很简单的!
[/Quote]

oh,shit "其实防注入还是很简单的！”
看来又来一狂人。

不过这位兄弟提到的这个我觉得可取：“如有可能再建一个数据封装类来给数据传输加密”

cnzhouhai 2008-05-05

打赏
举报

[Quote=引用 46 楼 zpcoder 的回复:]
这个问题应该转到 SQL 时去, 建议使用SP. 这一点我也很赞同.

但T-SQL 有时间比SP要方便一点, 写好过滤 T-SQL 的方法后,还要做
到以下几点 (人个认为)

1、把所有 TextBox (Input type="text" ) 等输入信息的地方,限制一个最大输入长度。
这样至少可以给输入危险字符带来限制，这还是有点作用的，况且这样做并不难。(JavaScript遍历)

2、楼主也提到过，URL可能也会传输入危险字符。这个解决，你可以用URL重写功…

这样应该比较不错。
还有，我想随便问一下楼主，你确认无名的黑客就是SQL注入攻击您的网站的？
或者说你的服务器,本身就是他的一个肉机或别的什么?
[/Quote]

这个好，讲的几点都很实在，也实用^_^

回答你的问题：
你确认无名的黑客就是SQL注入攻击您的网站的？ ”
对于这个问题，哈哈。本帖旨在对SQL防注入做一个深入讨论，最后作个总结，大家以后在SQL防注入上就不需要再花太多时间了。

你想到的可能需要再开个帖：如果让你的服务器远离肉鸡的命运！

cnzhouhai 2008-05-05

打赏
举报

[Quote=引用 99 楼 GengWH 的回复:]
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)";

是什么意思啊？
[/Quote]

正则表达式匹配危险字符串