SQL注入攻击的网络分析及防御方法

SQL注入攻击的网络分析及防御方法

　SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。

　　SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。

　　但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据，是高手与“菜鸟”的根本区别。下面从SOL注入的背景讲起，再谈谈如何防御等问题。

　　一 SQL注入攻击的背景：

　　在计算机技术高速发展的今天，越来越让人们头疼的是面临越来越“变态”和复杂的威胁网站技术，他们利用Internet 执行各种恶意活动，如身份窃取、私密信息窃取、带宽资源占用等。它们潜入之后，还会扩散并不断更新自己。这些活动常常利用用户的好奇心，在用户不知道或未来允许的情况下潜入用户的PC，不知不觉中，帐户里的资金就被转移了，公司讯息也被传送出去，危害十分严重。2006年8月16日，第一个Web威胁样本出现，截止到2006年10月25日，已经产生了第150个变种，并且，还在不断地演化下去。

　　网站威胁的目标定位有多个维度，是个人还是公司，还是某种行业，都有其考虑，甚至国家、地区、性别、种族、宗教等也成为发动攻击的原因或动机。攻击还会采用多种形态，甚至是复合形态，比如病毒、蠕虫、特洛伊、间谍软件、僵尸、网络钓鱼电子邮件、漏洞利用、下载程序、社会工程、rootkit、黑客，结果都可以导致用户信息受到危害，或者导致用户所需的服务被拒绝和劫持。从其来源说 Web威胁还可以分为内部攻击和外部攻击两类。前者主要来自信任网络，可能是用户执行了未授权访问或是无意中定制了恶意攻击；后者主要是由于网络漏洞被利用或者用户受到恶意程序制定者的专一攻击。

　　二 SQL注入攻击的网络分析：

　　SQL注入攻击是非常令人讨厌的安全漏洞，是所有的web开发人员，不管是什么平台，技术，还是数据层，需要确信他们理解和防止的东西。不幸的是，开发人员往往不集中花点时间在这上面，以至他们的应用，更糟糕的是，他们的客户极其容易受到攻击。

　　Michael Sutton 最近发表了一篇非常发人深省的帖子，讲述在公共网上这问题是多么地普遍。他用Google的Search API建了一个C#的客户端程序，寻找那些易受SQL 注入攻击的网站。其步骤很简单：

　　1、寻找那些带查询字符串的网站(例如，查询那些在URL里带有 "id=" 的URL)

　　2、给这些确定为动态的网站发送一个请求，改变其中的id=语句，带一个额外的单引号，来试图取消其中的SQL语句(例如，如 id=6' )

　　3、分析返回的回复，在其中查找象“SQL” 和“query”这样的词，这往往表示应用返回了详细的错误消息(这本身也是很糟糕的)

　　4、检查错误消息是否表示发送到SQL服务器的参数没有被正确加码(encoded)，如果如此，那么表示可对该网站进行SQL注入攻击。

对通过Google搜寻找到的1000个网站的随机取样测试，他检测到其中的11.3%有易受SQL注入攻击的可能。这非常，非常地可怕。这意味着黑客可以远程利用那些应用里的数据，获取任何没有hashed或加密的密码或信用卡数据，甚至有以管理员身份登陆进这些应用的可能。这不仅对开发网站的开发人员来说很糟糕，而且对使用网站的消费者或用户来说更糟糕，因为他们给网站提供了数据，想着网站是安全的呢。

　　那么SQL注入攻击到底是什么玩意？

　　有几种情形使得SQL注入攻击成为可能。最常见的原因是，你动态地构造了SQL语句，却没有使用正确地加了码(encoded)的参数。譬如，考虑这个SQL查询的编码，其目的是根据由查询字符串提供的社会保险号码(social security number)来查询作者(Authors)：


　　Dim SSN as String

　　Dim SqlQuery as String

　　SSN = Request.QueryString("SSN")

　　SqlQuery = "SELECT au_lname, au_fname FROM authors WHERE au_id = '" + SSN + "'"


　　如果你有象上面这个片断一样的SQL编码，那么你的整个数据库和应用可以远程地被黑掉。怎么会呢？在普通情形下，用户会使用一个社会保险号码来访问这个网站，编码是象这样执行的：


　　' URL to the page containing the above code

　　http://mysite.com/listauthordetails.aspx?SSN=172-32-9999

　　' SQL Query executed against the database

　　SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-9999'


　　 这是开发人员预期的做法，通过社会保险号码来查询数据库中作者的信息。但因为参数值没有被正确地加码，黑客可以很容易地修改查询字符串的值，在要执行的值后面嵌入附加的SQL语句 。譬如，


　　' URL to the page containing the above code

　　http://mysite.com/listauthordetails.aspx?SSN=172-32-9999';DROP DATABASE pubs --

　　' SQL Query executed against the database

　　SELECT au_lname, au_fname FROM authors WHERE au_id = '';DROP DATABASE pubs --


　　注意到没有，可以在SSN查询字符串值的后面添加“ ';DROP DATABASE pubs -- ”，通过 “;”字符来终止当前的SQL语句，然后添加了自己的恶意的SQL语句，然后把语句的其他部分用“--”字符串注释掉。因为是手工在编码里构造SQL语句，最后把这个字符串传给了数据库，数据库会先对authors表进行查询，然后把我们的pubs数据库删除。“砰(bang)”的一声，数据库就没了！

　　万一你认为匿名黑客删除你的数据库的结果很坏，但不幸的是，实际上，这在SQL注入攻击所涉及的情形中算是比较好的。一个黑客可以不单纯摧毁数据，而是使用上面这个编码的弱点，执行一个JOIN语句，来获取你数据库里的所有数据，显示在页面上，允许他们获取用户名，密码，信用卡号码等等。他们也可以添加 UPDATE/INSERT 语句改变产品的价格，添加新的管理员账号，真的搞砸你(screw up your life)呢。想象一下，到月底检查库存时，发现你库房里的实际产品数与你的账目系统(accounting system)汇报的数目有所不同。
三 如何防范SQL注入攻击

　　SQL注入攻击是你需要担心的事情，不管你用什么web编程技术，再说所有的web框架都需要担心这个的。你需要遵循几条非常基本的规则：

　　1、在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。大多数的数据API，包括ADO和ADO.NET，有这样的支持，允许你指定所提供的参数的确切类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded了，来避免黑客利用它们。一定要从始到终地使用这些特性。

　　例如，在ADO.NET里对动态SQL，你可以象下面这样重写上述的语句，使之安全：


　　Dim SSN as String = Request.QueryString("SSN")

　　Dim cmd As new SqlCommand("SELECT au_lname, au_fname FROM authors WHERE au_id = @au_id")

　　Dim param = new SqlParameter("au_id", SqlDbType.VarChar)

　　param.Value = SSN

　　cmd.Parameters.Add(param)


　　这将防止有人试图偷偷注入另外的SQL表达式(因为ADO.NET知道对au_id的字符串值进行加码)，以及避免其他数据问题(譬如不正确地转换数值类型等)。注意，VS 2005内置的TableAdapter/DataSet设计器自动使用这个机制，ASP.NET 2.0数据源控件也是如此。

　　一个常见的错误知觉(misperception)是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。

　　2、在部署你的应用前，始终要做安全审评(security review)。建立一个正式的安全过程(formal security process)，在每次你做更新时，对所有的编码做审评。后面一点特别重要。很多次我听说开发队伍在正式上线(going live)前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关，推说，“就是一个小小的更新，我们以后再做编码审评好了”。请始终坚持做安全审评。

　　3、千万别把敏感性数据在数据库里以明文存放。我个人的意见是，密码应该总是在单向(one-way )hashed过后再存放，我甚至不喜欢将它们在加密后存放。在默认设置下，ASP.NET 2.0 Membership API 自动为你这么做，还同时实现了安全的SALT 随机化行为(SALT randomization behavior)。如果你决定建立自己的成员数据库，我建议你查看一下我们在这里发表的我们自己的Membership provider的源码。同时也确定对你的数据库里的信用卡和其他的私有数据进行了加密。这样即使你的数据库被人入侵(compromised)了的话，起码你的客户的私有数据不会被人利用。

　　4、确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。这么做是非常重要的，有助于捕捉住 (catch)“就是一个小小的更新，所有不会有安全问题”的情形带来的疏忽，来提供额外的安全层以避免偶然地引进坏的安全缺陷到你的应用里去。

　　5、锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限从你的account payables表来生成报表，那么确认你禁止它对此表的 insert/update/delete 的权限。

　　6、很多新手从网上下载SQL通用防注入系统的程序，在需要防范注入的页面头部用 来防止别人进行手动注入测试。

　　可是如果通过SQL注入分析器就可轻松跳过防注入系统并自动分析其注入点。然后只需要几分钟，你的管理员账号及密码就会被分析出来。

　　7、对于注入分析器的防范，笔者通过实验，发现了一种简单有效的防范方法。首先我们要知道SQL注入分析器是如何工作的。在操作过程中，发现软件并不是冲着“admin”管理员账号去的，而是冲着权限（如flag=1）去的。这样一来，无论你的管理员账号怎么变都无法逃过检测。

　　第三步：既然无法逃过检测，那我们就做两个账号，一个是普通的管理员账号，一个是防止注入的账号，为什么这么说呢？笔者想，如果找一个权限最大的账号制造假象，吸引软件的检测，而这个账号里的内容是大于千字以上的中文字符，就会迫使软件对这个账号进行分析的时候进入全负荷状态甚至资源耗尽而死机。下面我们就来修改数据库吧。

　　1、对表结构进行修改。将管理员的账号字段的数据类型进行修改，文本型改成最大字段255（其实也够了，如果还想做得再大点，可以选择备注型），密码的字段也进行相同设置。

　　2、对表进行修改。设置管理员权限的账号放在ID1，并输入大量中文字符（最好大于100个字）。

　　3、把真正的管理员密码放在ID2后的任何一个位置

　　由于SQL注入攻击针对的是应用开发过程中的编程不严密，因而对于绝大多数防火墙来说，这种攻击是“合法”的。问题的解决只有依赖于完善编程。专门针对SQL注入攻击的工具较少，Wpoison对于用asp，php进行的开发有一定帮助。



有关asp的注入
ASP编程门槛很低，新手很容易上路。在一段不长的时间里，新手往往就已经能够编出看来比较完美的动态网站，在功能上，老手能做到的，新手也能够做到。那么新手与老手就没区别了吗？这里面区别可就大了，只不过外行人很难一眼就看出来罢了。在界面的友好性、运行性能以及网站的安全性方面是新手与老手之间区别的三个集中点。而在安全性方面，新手最容易忽略的问题就是SQL注入漏洞的问题。用NBSI 2.0对网上的一些ASP网站稍加扫描，就能发现许多ASP网站存在SQL注入漏洞，教育网里高校内部机构的一些网站这种漏洞就更普遍了，可能这是因为这些网站大都是一些学生做的缘故吧，虽然个个都很聪明，可是毕竟没有经验，而且处于学习中，难免漏洞多多了。本文主要讲讲SQL注入的防范措施，而要明白这些防范措施的用处，须先详细讲解利用SQL注入漏洞入侵的过程。新手们看明白啦。

相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。如这是一个正常的网址http://localhost/lawjia/show.asp?ID=444，将这个网址提交到服务器后，服务器将进行类似Select * from 表名 where 字段="&ID的查询(ID即客户端提交的参数，本例是即444)，再将查询结果返回给客户端，如果这里客户端故意提交这么一个网址：

http://localhost/lawjia/show.asp?ID=444 and user>0，这时，服务器运行Select * from 表名 where 字段=444 and user>0这样的查询，当然，这个语句是运行不下去的，肯定出错，错误信息如下：

·错误类型：

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]将 nvarchar 值 'sonybb' 转换为数据类型为 int 的列时发生语法错误。
/lawjia/show.asp, 第 47 行

但是别有用心的人从这个出错信息中，可以获得以下信息：该站使用MS＿SQL数据库，用ODBC连接，连接帐号名为：sonybb。所谓SQL注入（SQL Injection），就是利用程序员对用户输入数据的合法性检测不严或不检测的特点，故意从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取想得到的资料。通常别有用心者的目标是获取网站管理员的帐号和密码。比如当某个人知道网站管理员帐号存在表login中，管理员帐号名为admin，他想知道管理员密码，这里他从客户端接着提交这样一个网址：
http://localhost/lawjia/show.asp?ID=444 and (Select password from login where user_name='admin')>0，返回的出错信息如下：

·错误类型：

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]将 varchar 值 '！＠＃＊＆admin' 转换为数据类型为 int 的列时发生语法错误。
/lawjia/show.asp, 第 47 行

你知道吗？上面标红的部分就是管理员帐号admin的密码！虽然很复杂，让人看几遍也记不住的，但它就这样显示在你面前了，这时您就可以用这个帐号和密码接管人家的网站了！这时你可能还会说，如果他不是事先知道管理员帐号存在表login中，而且知道管理员帐号为admin，那他就不可能获得管理员密码。你错了，只要人家愿意多花时间尝试，他将可以获得数据库连接帐号权限内所能获得的所有信息！具体过程请参看网上的这篇文章：SQL注入漏洞全接触。

当然这个过程是很烦琐的而且要花费很多的时间，如果只能以这种手动方式进行SQL注入入侵的话，那么许多存在SQL注入漏洞的ASP网站会安全很多了，不是漏洞不存在了，而是利用这个漏洞入侵的成本太高了。但是如果利用专门的黑客工具来入侵的话，那情况就大大不同了。手动方式进行SQL注入入侵至少需要半天或一天乃至很多天的时间，而利用专门的工具来入侵就只需要几分钟时间了（视网速快慢决定），再利用获得的管理帐号和密码，上传一个从网上下载的ASP后门程序，就轻易获得整个网站的管理权限了，甚至整个服务器的管理权限。最有名的一种SQL注入入侵工具是NBSI 2.0，现在已经出到2.0版本了，不过，人家正式名称不叫SQL注入入侵工具，而叫做网站安全漏洞检测工具。有了这个所谓的检测工具，使得入侵存在SQL注入漏洞的ASP网站成了小儿科的游戏，那些既不懂ASP又不懂SQL、年纪小小的男性青年常常得以在一天之内入侵十多个ASP网站，他们以此获得内心的极大满足。他们似乎也非常讲究职业道德，往往并不破坏网站数据和系统，常见的破坏方式大都仅仅是改换掉网站的主页，留下"善意的警告"，如：你的网站存在SQL注入漏洞，请管理员做好防范措施！并声明"我没有破坏数据和系统"，有的还要借机发布一下他的倡导："国内网站大家不要入侵，有本事入侵小日本的！"，最后，签上他的鼎鼎大名是必不可少的程序。

如此大的成就多数情况下仅需动动鼠标就做到了。打开最新版的NBSI 2.0，如图1所示：输入地址到A区，注意网址必须是带传递参数的那种，点击右边的检测按钮，即出来B区信息，显示当前用户为sonybb的权限为PUBLIC，当前库为lawjia。有点可惜啊，如果是SA权限的话，就可以跨库注入了。不过，这个权限也足够获取该网站管理员帐号和密码了。点C区下的自动猜解按钮，即出来当前库lawjia中的各种表，哇，login表中一定是存管理员帐号和密码的吧？选中它吧，接着点击D区下的自动猜解按钮，立即出来login表里的列名称，果然是存放用户名和密码的啊，太棒了！赶快打上勾，迫不急待的点击E区下的自动猜解按钮。激动人心的时刻就要到来啦，只见唰唰地几下，帐号与密码全部出来了。剩下的事就是辨别哪一个帐号是管理员了。




图1（图中的示例网站在作者本地电脑上运行）

不知那些没注意过SQL注入漏洞的ASP程序员们看了上图的例子，要作何感想呢？是不是觉得这个所谓的网站安全漏洞检测工具SBSI 2.0简直就是MS_SQL的企业管理器呢？只不过人家不需要帐号和密码就可以查看您数据库里的所有信息了。如果您的网站就这样被人不费吹灰之力入侵了，您是不是要吐几升血了呢？也许您已经为系统安全费尽心思了，装补丁、安防火墙、装杀毒软件、巧妙配置IIS及数据库用户权限，但您就是没有注意到SQL注入漏洞，于是"千里之堤，溃于蚁穴"。防火墙与杀毒软件对SQL注入是没办法防范的，因为SQL注入入侵跟普通的WEB页面访问没什么区别，所以往往是防不甚防。而且一个服务器上放置的网站往往是有很多个的，服务器管理员不可能挨个网站挨个页面的审查其是否存在SQL注入漏洞。那么应该如何防范SQL注入入侵呢？作为服务器管理员或网站程序员应该分别怎么做呢？服务器管理员要做的事主要是配置IIS和数据库用户权限，而网站程序员主要是要在程序代码编写上防范SQL注入入侵。下面详细叙述：

对了服务器管理员，既然你不可能挨个检查每个网站是否存在SQL注入漏洞，那么就来个一个绝招。这个绝招能有效防止SQL注入入侵而且"省心又省力，效果真好！"SQL注入入侵是根据IIS给出的ASP错误提示信息来入侵的，如果你把IIS设置成不管出什么样的ASP错误，只给出一种错误提示信息，即http 500错误，那么人家就没办法入侵了。具体设置请参看图2。主要把500:100这个错误的默认提示页面 C:\WINDOWS\Help\iisHelp\common\500-100.asp改成
C:\WINDOWS\Help\iisHelp\common\500.htm即可，这时，无论ASP运行中出什么错，服务器都只提示HTTP 500错误。




图2、IIS出错信息设置


但是这样设置一个不好的地方是程序员编写的代码出错时，服务器不给出详细的错误提示信息，会给程序员带来很大的不便。不过，服务器毕竟不是测试代码的地方，应坚持安全稳定第一，这样设置也是无可厚非的，事实上许多服务器的出错信息都是如此设置。

服务器管理员还应在IIS中为每个网站设置好执行权限，可千万别给人家静态网站以"脚本和可执行"权限。一般情况下给个"纯脚本"权限就够了，对于那些通过网站后台管理中心上传的文件存放的目录，就更吝啬一点吧，执行权限设为"无"好了，这样做是为了防止人家上传ASP木马，执行权限设为"无"，人家上传ASP木马也运行不了。一般情况下，SQL注入漏洞仅是涉及一个网站安全的事，如果人家通过这个漏洞上传了ASP木马并运行起来，那整个服务器都失陷了。所以有远见的、有责任心的服务器管理员应该十分吝啬的配置IIS的执行权限。

同样的吝啬态度应适用于数据库用户的权限配置上，当然这里数据库是指MS＿SQL啦，ACCESS都没有用户权限配置这一步骤。如果PUBLIC权限足够使用的绝不给再高的权限，可千万别把SA级别的权限随随便便地给人家啊。那个所谓的网站安全漏洞检测工具NBSI 2.0可有跨库进行SQL注入的功能啊，如果你把SA权限给了存在SQL注入漏洞的库，那其它库就不保啦！城门失火，殃及池鱼呀。而人家还可以通过调用xp_cmdshell命令得到系统的最高权限。具体步骤还是请参看上面提到的那篇《SQL注入漏洞全接触》这篇文章吧。

接下来要讲讲程序员的防范措施了。程序主要要做两件事，最重要的一件事，当然是对客户端提交的变量参数进行仔细地检测啦。对客户端提交的变量进行检查以防止SQL注入，有各种方法，到http://community.csdn.net/上搜索一下，你能获得许多有益信息。这里介绍一种现成的方法，别人已经写好了检测代码，拿来用一下，不用自己辛苦啦。那就是"枫叶SQL通用防注入V1.0 ASP版"，这是一段对用户通过网址提交过来的变量参数进行检查的代码，发现客户端提交的参数中有"exec、insert、select、delete、from、update、count、user、xp_cmdshell、add、net、Asc"等用于SQL注入的常用字符时，立即停止执行ASP并给出警告信息或转向出错页面。大家可以到网上搜索一下，下载这段代码，存为一个ASP页面，如checkSQL.asp，把这个页面include到每个需要带参数查询SQL数据库ASP页面中，记住，只要加一行这样的<!--#include file="checkSQL.asp"-->代码就行了。

程序员要做的第二件事是给用户密码加密啦。比如用MD5加密。MD5是没有反向算法,不能解密的。人家即使知道经加密后存在数据库里的像乱码一样的密码，他也没办法知道原始密码了。不过，人家可以用UPDATE方法用他的密码代替你的密码，但这个操作还是有点麻烦，人家可能会怕麻烦而放弃。而那个所谓的网站安全漏洞检测工具NBSI 2.0是没有提供UPDATE操作功能的，所以用MD5加密后，人家仅用NBSI 2.0而不辅以手动操作的话，就不可能获得网站管理员帐号的密码，这将挡住许多菜鸟级的攻击者，至少那些既不懂ASP又不懂SQL、年纪小小的男性青年是没有办法啦！

文章写到这，已经够长了，本来还想对那些所谓的网站安全漏洞检测工具如NBSI之流的黑客工具进行一番理性的探讨的，看来还是放弃好了。为了增强网站安全，了解攻击手段是必须的，但是，利用漏洞开发专门的黑客工具，使那些其实并不具备必要的网络技术和网络安全知识的人（就是文中提到的"既不懂ASP又不懂SQL、年纪小小的男性青年"）轻而易举地侵入一家网站，这除了为许多网络管理员制造麻烦外，是否还具有加强网络安全意识提高网络安全水平的功效呢？