Sql 注入

首先我想谢谢园子的朋友们，是你们提醒我写内容有错误，记得曾经电子商务之数据存储流程（五）里面说到“选存储过程+传递参数用SqlParameter是因为，除非是ADO.NET有漏洞，那么就绝对不会发生SQL注入”。Keep Walking大哥也在关于防止sql注入的几种手段（二）中举出来一个例子说明我说的上句话是错误的。说实话当时我还是对SQL注入不是很了解，也没有遇到过SQL注入，也不是很关心它。但是我想安全的问题我们一定要非常注意，于是这些时候花了一些时间来学习了SQL注入。

什么是SQL注入

　　可能大家还不是对SQL注入这个概念不是很清楚，简单地说,SQL注入就是攻击者通过正常的WEB页面,把自己SQL代码传入到应用程序中,从而通过执行非程序员预期的SQL代码,达到窃取数据或破坏的目的。

　　当应用程序使用输入内容来构造动态SQL语句以访问数据库时，会发生SQL注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生SQL注入。SQL注入可能导致攻击者使用应用程序登陆在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库，这种问题会变得很严重。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或者作为存储过程的输入参数，这些表单特别容易受到SQL注入的攻击。而许多网站程序在编写时，没有对用户输入的合法性进行判断或者程序中本身的变量处理不当，使应用程序存在安全隐患。这样，用户就可以提交一段数据库查询的代码，根据程序返回的结果，获得一些敏感的信息或者控制整个服务器，于是SQL注入就发生了。

一般SQL注入

　　在Web 应用程序的登录验证程序中,一般有用户名(username) 和密码(password) 两个参数,程序会通过用户所提交输入的用户名和密码来执行授权操作。我们有很多人喜欢将SQL语句拼接起来。例如：

　　Select * from users where username =’ txtusername.Text ’ and  password =’ txtpassword.Text ’

　　其原理是通过查找users 表中的用户名(username) 和密码(password) 的结果来进行授权访问, 在txtusername.Text为mysql，txtpassword.Text为mary，那么SQL查询语句就为：

　　Select * from users where username =’ mysql ’ and  password  =’ mary ’

　　如果分别给txtusername.Text 和txtpassword.Text赋值’ or ‘1’ = ‘1’ --和abc。那么,SQL 脚本解释器中的上述语句就会变为:

　　Select * from users where username =’’or  ‘1’ = ‘1’  -- and password =’abc’

　　该语句中进行了两个条件判断,只要一个条件成立,就会执行成功。而'1'='1'在逻辑判断上是恒成立的,后面的"--" 表示注释,即后面所有的语句为注释语句这样我们就成功登录。即SQL注入成功.

　　如果我们给txtusername.Text赋值为:’;drop table users--即:

　　Select * from users where username =’’;drop table users-- and password =’abc’

　　整个用户表就没有了，当然这里要猜出数据表名称。想想是多么可怕的事情。

　　好我想大家在这里已经大致明白了一般SQL注入了，试想下您的登录程序会不会出现我上述的情况。

防范SQL注入

     那么现在大家都在思考怎么防范SQL注入了这里给出一点个人的建议

1.限制错误信息的输出

　　这个方法不能阻止SQL注入，但是会加大SQL注入的难度，不会让注入者轻易得到一些信息，让他们任意破坏数据库。SQL Server有一些系统变量，如果我们没有限制错误信息的输出，那么注入着可以直接从出错信息获取，例如（假定这里用的string即字符类型并可以发生SQL注入）：http://www.xxx.com/showdetail.aspx?id=49 and user>0 这句语句很简单，但却包含了SQL Server特有注入方法的精髓，。首先看看它的含义：首先，前面的语句是正常的，重点在and user>0，我们知道，user是SQL Server的一个内置变量，它的值是当前连接的用户名，类型为nvarchar。拿一个nvarchar的值跟int的数0比较，系统会先试图将nvarchar的值转成int型，当然，转的过程中肯定会出错，SQL Server的出错提示是：将nvarchar值 ”abc” 转换数据类型为 int 的列时发生语法错误，呵呵，abc正是变量user的值，这样，注入着就拿到了数据库的用户名。

　　众所周知，SQL Server的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的Administrator了。上面的方法可以很方便的测试出是否是用sa登录，要注意的是：如果是sa登录，提示是将”dbo”转换成int的列发生错误，而不是”sa”。

　　当然注入者还可以输入不同的信息来得到他们想要的信息 ，上面只是其中一个例子，所以我们要限制错误信息的输出，从而保护我们的数据库数据，这里我给出.NET限制错误信息的方法：

　　在Web.Config文件中设置

　　<customErrors mode="On" defaultRedirect="error.aspx">

　　</customErrors>

　　这样当发生错误时候就不会讲信息泄露给外人。

2.限制访问数据库帐号的权限

　　对于数据库的任何操作都是以某种特定身份和相应权限来完成的,SQL语句执行前,在数据库服务器端都有一个用户权限验证的过程,只有具备相应权限的帐号才可能执行相应权限内的SQL语句。因此,限制数据库帐号权限,实际上就阻断了某些SQL语句执行的可能。不过,这种方法并不能根本解决SQL注入问题,因为连接数据库的帐号几乎总是比其他单个用户帐号拥有更多的权限。通过限制贴帐号权限,可以防止删除表的攻击,但不能阻止攻击者偷看别人的信息。

3.参数化使用命令

　　参数化命令是在SQL文本中使用占位符的命令。占位符表示需要动态替换的数据,它们通过Command对象Parameters集合来传送。能导致攻击的SQL代码可以写成:

Select * from employee where userID=@userID;

　　如果用户输入: 09105022’OR ‘1’=’1,将得不到何记录,因为没有一个用户ID与文本框中输入的’ 09105022’OR ‘1’=’1’相等。参数化命令的语法随提供程序的不同略有差异。对于SQL SERVER提供程序,参数化命令使用命名的占位符(具有唯一的名字),而对于OLE DB提供程序,每个硬编码的值被问号代替。使用OLE DB提供程序时,需要保证参数的顺序和它们出现在SQL字符串中的位置一致。SQL SERVER提供程序没有这样的需求,因为它们用名字和占位符匹配。

4.调用存储过程

　　存储过程是存储在数据库服务器上的一系列SQL代码,存储过程与函数相似,有良好的逻辑封装结构,可以接收和返回数据。使用存储过程可以使代码更易于维护,因为对存储过程的更改不会导致应用程序的重新编译,使用存储过程还可以节省带宽,提高应用程序性能。因为存储过程是存储在数据库服务端的独立的封装体,调用存储过程可以保证应用程序只执行存储过程中的固定代码,从而杜绝SQL语句注入的可能。结合上述所讲的参数化命令,可以实现SQL代码可以实现的任何功能,并进一步提高应用程序的安全等级。

　　今天就写到这吧，后面还有一些防范的方法，可能更要实用一些，就在后面的文章介绍吧

 

 

 

 

 

5.限制输入长度

　　如果在Web页面上使用文本框收集用户输入的数据,使用文本框的MaxLength属性来限制用户输入过长的字符也是一个很好的方法,因为用户的输入不够长,也就减少了贴入大量脚本的可能性。程序员可以针对需要收集的数据类型作出一个相应的限制策略。

6.URL重写技术

        我们利用URL重写技术过滤一些SQL注入字符，从而达到防御SQL注入。因为许多SQL注入是从URL输入发生的。

7.传递参数尽量不是字符

　　假设我们显示一篇新闻的页面，从URL传递参数中获得newid我们可能会随手写下下面的代码：   

　　string newsid = Request.QueryString["newsid"];
　　string newssql = "select * from news where newsid=" + newsid;

　　如果传递过来的参数是数字字符就没有问题。但是如果传递过来的newsid是“1 delete from table ”的话，那么sql的值就变成了“select * from table where newsid=1 delete from news”。发生注入成功。但是这里改为

        int newsid=int.Parse(Request.QueryString["newsid"].ToString());

        string newssql = "select * from news where newsid=" + newsid.Tostring();

        这里如果还是上面"1 delete from table "会发生错误，因为在转换时候出现了错误

        从上面的一个小例子，我们得出在传递参数时候尽量不要用字符，免得被注入。

 

　　最后是我想扩展下利用URL重写技术来过滤一些SQL注入字符，首先这里有一篇关于URL重写的文章，我的基本思想是可以利用它，屏蔽一些危险的SQL注入字符串，这些字符串我们可以人为的设定，毕竟我们还是根据特定的环境设定我们防御措施。首先我们在ModuleRewriter类中的Rewrite函数得到绝对的URL判断其中是否有危险字符，如果有我们就将它链接到一个提示用户您输入危险的URL地址。如果不是我们继续判断是否触发了其他的URL重写的规则，触发了就重写。这样就大致上能在URL上防御危险字符。

代码

<configSections>
        <section name="RewriterConfig" type="URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter" />
</configSections>
<RewriterConfig>
    <Rules>
           <RewriterRule>
                <LookFor>~/d(/d+)/.aspx</LookFor>
                <SendTo>~/Default_sql_error.aspx</SendTo>
            </RewriterRule>
            <RewriterRule>
                <LookFor>~/d(/d+)/.aspx</LookFor>
                <SendTo>~/Default2.aspx</SendTo>
            </RewriterRule>
        </Rules>
</RewriterConfig>
<httpModules>
        <add type="URLRewriter.ModuleRewriter, URLRewriter" name="ModuleRewriter" />
</httpModules>

 

        上面是要在web.config配置文件加上的内容，这里我加上了两个重写规则，第一个规则是专门针对满足这个正则表达式的页面URL查看是否有危险字符，有危险字符就会发送到Default_sql_error.aspx页面，来示警。这里我假定会发生危险字符注入的页面时以"d"字符开头并加上数字的页面（这里我们可以根据实际情况自己定义，看哪些页面URL容易发生我们就制定这些页面的正则表达式），第二个是一般URL重写。因为这里我采用的是HTTP模块执行URL重写，所以加上<httpModules></httpModules>这一块。

         第二步就是要在重写Rewrite函数了

代码

        protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
        {
            // 获得配置规则
            RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;
            
           //获得绝对的URL
            Uri url = app.Request.Url;

            // 判断url 中是否含有SQL 注入攻击敏感的字符或字符串,如果存在,sqlatFlag = 1 ;
            string urlstr = url.AbsoluteUri;
            int sqlatFlag = 0;

            //这里我们根据实际情况随便编写，我这里这是随便列举了几个
            string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";

            string[] split = words.Split(',');
            foreach (string s in split)
            {
                if (urlstr.IndexOf(s.ToUpper()) > 0)
                {
                    sqlatFlag = 1;
                    break;
                }
            }
            if (sqlatFlag == 1)
            {
                // 创建regex
                Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
                // 找到匹配的规则,进行必要的替换
                string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
                // 重写URL
                RewriterUtils.RewriteUrl(app.Context, sendToUrl);
            }
            else
            {
                // 遍历除rules[0 ]以外的其他URL 重写规则
                for (int i = 1; i < rules.Count; i++)
                {
                    // 获得要查找的模式,并且解析URL (转换为相应的目录)
                    string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
                    // 创建regex
                    Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
                    // 查看是否找到了匹配的规则
                    if (re.IsMatch(requestedPath))
                    {
                        // 找到了匹配的规则, 进行必要的替换
                        string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
                        // 重写URL
                        RewriterUtils.RewriteUrl(app.Context, sendToUrl);
                        break;
                        // 退出For 循环
                    }
                }
            }
        }

 

 那么下一步就是检验例子了

首先我们输入http://localhost:4563/web/Default.aspx?id=1;-- 

这样http://localhost:4563/web/Default.aspx?id=1;-- 没有改变，就会显示Default_sql_error.aspx里内容“您输入了危险字符”。 
再输入http://localhost:4563/web/D11.aspx就会显示 Default2.aspx内容，因为这里触发了第二个重写规则

 试验成功。

 

　　当然用URL防SQL只是我想到一种怪癖思路，大家如果有什么特别方法可以共同考论一下，还是引用前辈们话“见招拆招”遇到实际的问题我们就根据实际情况解决，选用那个最实用的方法。