SQL注入攻击是黑客对数据库进行攻击的常用手段.docx

《SQL注入攻击是黑客对数据库进行攻击的常用手段.docx》由会员分享，可在线阅读，更多相关《SQL注入攻击是黑客对数据库进行攻击的常用手段.docx（7页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、SQL 注入攻击是黑客对数据库进展攻击的常用手段之一。随着B/S 模式应用开发的进展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及阅历也参差不齐，相当大一局部程序员在编写代码的时候，没有对用户输入数据的合法性进展推断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，依据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即 SQL 注入。SQL 注入是从正常的WWW 端口访问，而且外表看起来跟一般的 Web 页面访问没什么区分，所以目前市面的防火墙都不会对 SQL 注入发出警报，假设治理员没查看 IIS 日志的习惯，可能被入侵很长时间都

2、不会觉察。但是，SQL 注入的手法相当敏捷，在注入的时候会遇到很多意外的状况。能不能依据具体状况进展分析，构造奇异的 SQL 语句，从而成功猎取想要的数据，是高手与“菜鸟” 的根本区分。下面从SOL 注入的背景讲起，再谈谈如何防范等问题。 SQL 注入攻击的背景：在计算机技术高速进展的今日，越来越让人们头疼的是面临越来越“变态”和简单的威 胁网站技术，他们利用Internet 执行各种恶意活动，如身份窃取、私密信息窃取、带宽资源占用等。它们潜入之后，还会集中并不断更自己。这些活动常常利用用户的古怪心，在用 户不知道或将来允许的状况下潜入用户的PC，不知不觉中，帐户里的资金就被转移了，公 司讯息

3、也被传送出去，危害格外严峻。2006 年 8 月 16 日，第一个 Web 威逼样本消灭，截止到 2006 年 10 月 25 日，已经产生了第 150 个变种，并且，还在不断地演化下去。网站威逼的目标定位有多个维度，是个人还是公司，还是某种行业，都有其考虑，甚至 国家、地区、性别、种族、宗教等也成为发动攻击的缘由或动机。攻击还会承受多种形态， 甚至是复合形态，比方病毒、蠕虫、特洛伊、间谍软件、僵尸、网络钓鱼电子邮件、漏洞利用、下载程序、社会工程、rootkit、黑客，结果都可以导致用户信息受到危害，或者导致用 户所需的效劳被拒绝和劫持。从其来源说 Web 威逼还可以分为内部攻击和外部攻击两类

4、。前者主要来自信任网络，可能是用户执行了未授权访问或是无意中定制了恶意攻击;后者主 要是由于网络漏洞被利用或者用户受到恶意程序制定者的专一攻击。二 SQL 注入攻击的网络分析：SQL 注入攻击是格外令人厌烦的安全漏洞，是全部的 web 开发人员，不管是什么平台， 技术，还是数据层，需要确信他们理解和防止的东西。不幸的是，开发人员往往不集中花点 时间在这上面，以至他们的应用，更糟糕的是，他们的客户极其简洁受到攻击。Michael Sutton 最近发表了一篇格外发人深省的帖子，表达在公共网上这问题是多么地普遍。他用Google 的 Search API 建了一个C#的客户端程序，查找那些易受SQ

5、L 注入攻击的网站。其步骤很简洁：1、查找那些带查询字符串的网站(例如，查询那些在 URL 里带有 “id=“ 的 URL)2、给这些确定为动态的网站发送一个恳求，转变其中的 id=语句，带一个额外的单引号，来试图取消其中的SQL 语句(例如，如 id=6” )3、分析返回的回复，在其中查找象“SQL” 和“query”这样的词，这往往表示应用返回了具体的错误消息(这本身也是很糟糕的)4、检查错误消息是否表示发送到 SQL 效劳器的参数没有被正确加码(encoded)，假设如此，那么表示可对该网站进展SQL 注入攻击。对通过Google 搜查找到的 1000 个网站的随机取样测试，他检测到其中

6、的 11.3%有易受SQL 注入攻击的可能。这格外，格外地可怕。这意味着黑客可以远程利用那些应用里的数据，猎取任何没有 hashed 或加密的密码或信用卡数据，甚至有以治理员身份登陆进这些应用的可能。这不仅对开发网站的开发人员来说很糟糕，而且对使用网站的消费者或用户来说更糟糕，由于他们给网站供给了数据，想着网站是安全的呢。那么SQL 注入攻击到底是什么玩意?有几种情形使得SQL 注入攻击成为可能。最常见的缘由是，你动态地构造了 SQL 语句， 却没有使用正确地加了码(encoded)的参数。譬如，考虑这个 SQL 查询的编码，其目的是依据由查询字符串供给的社会保险号码(social secur

7、ity number)来查询作者(Authors)：Dim SSN as String Dim SqlQuery as StringSSN = Request.QueryString(“SSN“)SqlQuery = “SELECT au_lname, au_fname FROM authors WHERE au_id = ”“ + SSN + “”“假设你有象上面这个片断一样的 SQL 编码，那么你的整个数据库和应用可以远程地被黑掉。怎么会呢?在一般情形下，用户会使用一个社会保险号码来访问这个网站，编码是象这样执行的：” URL to the containing the above cod

8、e :/mysite /listauthordetails.aspx?SSN=172-32-9999 ” SQL Query executed against the databaseSELECT au_lname, au_fname FROM authors WHERE au_id = ”172-32-9999”这是开发人员预期的做法，通过社会保险号码来查询数据库中作者的信息。但由于参数值没有被正确地加码，黑客可以很简洁地修改查询字符串的值，在要执行的值后面嵌入附加的 SQL 语句 。譬如，” URL to the containing the above code :/mysite /li

9、stauthordetails.aspx?SSN=172-32-9999”;DROP DATABASE pubs - ” SQL Query executed against the databaseSELECT au_lname, au_fname FROM authors WHERE au_id = ”;DROP DATABASE pubs -留意到没有，可以在SSN 查询字符串值的后面添加“ ”;DROP DATABASE pubs - ”，通过 “;”字符来终止当前的SQL 语句，然后添加了自己的恶意的SQL 语句，然后把语句的其他局部用“-”字符串注释掉。由于是手工在编码里构造 SQ

10、L 语句，最终把这个字符串传给了数据库，数据库会先对authors 表进展查询，然后把我们的pubs 数据库删除。“砰(bang)”的一声，数据库就没了!万一你认为匿名黑客删除你的数据库的结果很坏，但不幸的是，实际上，这在SQL 注入攻击所涉及的情形中算是比较好的。一个黑客可以不单纯摧毁数据，而是使用上面这个编 码的弱点，执行一个JOIN 语句，来猎取你数据库里的全部数据，显示在页面上，允许他们猎取用户名，密码，信用卡号码等等。他们也可以添加 UPDATE/INSERT 语句转变产品的价格，添加的治理员账号，真的搞砸你(screw up yourlife)呢。想象一下，到月底检查库存时，觉察你

11、库房里的实际产品数与你的账目系统(accountingsystem)汇报的数目有所不同。三 如何防范SQL 注入攻击SQL 注入攻击是你需要担忧的事情，不管你用什么web 编程技术，再说全部的web 框架都需要担忧这个的。你需要遵循几条格外根本的规章：1、在构造动态 SQL 语句时，肯定要使用类安全(type-safe)的参数加码机制。大多数的数据API，包括 ADO 和 ADO.NET，有这样的支持，允许你指定所供给的参数的精准类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded 了，来避开黑客利用它们。肯定要从始到终地使用这些特性。例如，在ADO.NE

12、T 里对动态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 = SSNcmd.Parameters.Add(param)这将防止有人试图偷偷注入另外的SQL 表达式(由于 ADO.NET 知道

13、对 au_id 的字符串值进展加码)，以及避开其他数据问题(譬如不正确地转换数值类型等)。留意，VS 2005 内置的 TableAdapter/DataSet 设计器自动使用这个机制，ASP.NET 2.0 数据源控件也是如此。一个常见的错误知觉(misperception)是，假设你使用了存储过程或 ORM，你就完全不受SQL 注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很慎重， 或在用ORM 来定制一个查询时，你的做法是安全的。2、在部署你的应用前，始终要做安全审评(security review)。建立一个正式的安全过程(formal security proc

14、ess)，在每次你做更时，对全部的编码做审评。后面一点特别重要。很屡次我听说开发队伍在正式上线(going live)前会做很具体的安全审评，然后在几周或几个月之后他们做一些很小的更时，他们会跳过安全审评这关，推说，“就是一个小小的更，我们以后再做编码审评好了”。请始终坚持做安全审评。3、千万别把敏感性数据在数据库里以明文存放。我个人的意见是，密码应当总是在单向(one-way )hashed 过后再存放，我甚至不宠爱将它们在加密后存放。在默认设置下， ASP.NET 2.0 Membership API 自动为你这么做，还同时实现了安全的 SALT 随机化行为(SALT randomizat

15、ion behavior)。假设你打算建立自己的成员数据库，我建议你查看一下我们在这里发表的我们自己的Membership provider 的源码。同时也确定对你的数据库里的信用卡和其他的私有数据进展了加密。这样即使你的数据库被人入侵(compromised)了的话，起 码你的客户的私有数据不会被人利用。4、确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL 注入攻击。这么做是格外重要的，有助于捕获住(catch)“就是一个小小的更，全部不会有安全问题”的情形带来的疏忽，来供给额外的安全层以避开偶然地引进坏的安全缺陷到你的应用里去。5、锁定你的数据库的安全，只给访问数

16、据库的web 应用功能所需的最低的权限。假设web 应用不需要访问某些表，那么确认它没有访问这些表的权限。假设 web 应用只需要只读的权限从你的 account payables 表来生成报表， 那么确认你制止它对此表的insert/update/delete 的权限。6、很多手从网上下载 SQL 通用防注入系统的程序，在需要防范注入的页面头部用 来防止别人进展手动注入测试。可是假设通过 SQL 注入分析器就可轻松跳过防注入系统并自动分析其注入点。然后只需要几分钟，你的治理员账号及密码就会被分析出来。7、对于注入分析器的防范，笔者通过试验，觉察了一种简洁有效的防范方法。首先我们要知道SQL

17、注入分析器是如何工作的。在操作过程中，觉察软件并不是冲着“admin”治理员账号去的，而是冲着权限(如 flag=1)去的。这样一来，无论你的治理员账号怎么变都无法逃过检测。第三步：既然无法逃过检测，那我们就做两个账号，一个是一般的治理员账号，一个是防止注入的账号，为什么这么说呢?笔者想，假设找一个权限最大的账号制造假象，吸引软件的检测，而这个账号里的内容是大于千字以上的中文字符，就会迫使软件对这个账号进展 分析的时候进入全负荷状态甚至资源耗尽而死机。下面我们就来修改数据库吧。1、对表构造进展修改。将治理员的账号字段的数据类型进展修改，文本型改成最大字 段 255(其实也够了，假设还想做得再大

18、点，可以选择备注型)，密码的字段也进展一样设置。2、对表进展修改。设置治理员权限的账号放在 ID1，并输入大量中文字符(最好大于 100个字)。3、把真正的治理员密码放在ID2 后的任何一个位置由于 SQL 注入攻击针对的是应用开发过程中的编程不严密，因而对于绝大多数防火墙来说，这种攻击是“合法”的。问题的解决只有依靠于完善编程。特地针对SQL 注入攻击的工具较少，Wpoison 对于用asp，php 进展的开发有肯定帮助.。.大事背景迹象：依据 2008 年 5 月 19 日的估测，中国大陆、香港、台湾的 12 万网站均受到了 SQL 注入攻击。在大中华地区，一个“ ” 的脚本注入到了很多公

19、共网站， 包括政府、教育部门、非政府组织的慈善机构，以及一些企业的站点。攻击时间及规模：首次攻击在 2008 年 1 月，觉察至今的 5 个月里，经过微软安全支持团队的监控与分析，觉察 2008年 5 月 19 日的这次爆发并非第一起 SQL 注入攻击。在过去的 4 个月中，已有过 3 次大规模攻击：1. 2008 年 1 月初，包括 CA 等成千上万的网站受到了 SQL 注入攻击1,0001,000 页/天。2. 2008 年 3 月中旬，包括TrendMicro.jp 在内的网站受到了 SQL 注入攻击1,0001,000 页/ 天。3. 2008 年 4 月中旬，包括英国政府和联合国的网

20、站都受到了SQL 注入攻击1,0001,000 页/ 天。SQL 注入攻击行为产生的流程 黑客运用搜寻引擎查找网页上的漏洞，并运用自动化工具攻击网络效劳器。 一个 字符串附加到在后台运行的 SQL 效劳器中全部的文本或可变长字符串行中。 这个脚本与黑客所掌握效劳器连接。该效劳器含有一些常用软件的利用代码，如MicrosoftMS06-014，第三方软件漏洞Real Player, Global Link Lianzong, PPStorm Baofeng, Thunder Xunlei, Baidu Bar。有的时候还有一些 0day 漏洞，比方 10 天前公布的 GlobalLink Lia

21、nzong 0day。 当终端用户试图用 IE 扫瞄正常的网站时，由于这些网页都将从 SQL 效劳器猎取数据，这些数据同时包含了恶意脚本。而这些脚本会自动连接到黑客的网站。 假设终端用户没有打补丁，或尚未安装 Microsoft 或第三方软件的最更，那么他们的电脑就会被感染。事实上，在中国每天都有被攻击的网站，他们被感染上恶意代码，使其连向黑客掌握的网站。依据来自中国 Blackhat 组织的消息，这些攻击者并没有暴露自己的身份。这种攻击的目的是攻击者想要建立一个超大的肉鸡网络，然后将其卖给其他人，从中谋取利益。SQL 注入攻击大事响应的解决方案一旦 Web 效劳器遭到 SQL 注入攻击，请依

22、据以下步骤来保护您的网站： 关闭网站； 检查 IIS 日志，查找引起这次攻击的有漏洞的目标网页； 联系 Web 开发者，修改并加强 ASP 页面。小提示：此方法仅为一种变通的解决方法，只能临时解决SQL 注入问题。该网站可能在效劳器重联网后被再次注入。为了彻底解决这个问题，请参阅下文“预防 SQL 注入攻击的解决方案”。预防 SQL 注入攻击的解决方案这种 SQL 注入攻击是由 ASP 网页不符合安全编码的要求所引起的。为了防止攻击，需要验证全部网页的字符串输入的函数。比方说，带有用户名和密码输入框的网站登录页。也可以在微软的官方网站上找到安全指导和最正确实践的文档，来应对 SQL 注入攻击。

23、 用来缓解 SQL 注入攻击的最正确实践文章： :/msdn2.microsoft /en-us/magazine/cc163917.aspx 在 ASP.Net 中如何防止注入攻击： :/msdn.microsoft /en-us/library/bb355989.aspx 在 ASP.Net 中如何防止 SQL 注入攻击： :/msdn.microsoft /en-us/library/ms998271.aspx 在 ASP.Net 中如何防止跨域脚本攻击： :/msdn.microsoft /en-us/library/ms998274.aspx 设计指南： :/msdn.microsoft /en-us/library/aa302420.aspx 设计审查： :/msdn.microsoft /en-us/library/aa302421.aspx大局部的攻击大事是由第三方软件的漏洞所造成。假设您是客户端用户，那么请确保您的计算机系统中已安装了微软及第三方软件的最安全补丁，来尽量降低您的计算机被攻击的几率