SQL知识讲解.docVIP

SQL知识讲解 1.1概述 1.2背景 1.3字符编码 2.1综合测试 2.2测试过程 2.3分析结果 3.1绕过验证 3.2 SELECT 3.2.1 直接利用 号 3.2.2 基于UNION 3.2.3 利用结构错误查询表单 3.2.4 插入语句(圆扩号) 3.2.5 利用LIKE语句查询 3.2.6 死胡同 3.2.7 列的数目不匹配问题 3.2.8 附加的WHERE引号 表和域的枚举 3.2.10 单括号 3.3插入 3.4SQL服务器存储过程利用 4.1数据处理 4.2安全的SQL网页应用程序编写 5.1MS SQL Server 5.2MS Access Server 5.3 Oracle 关于 SPI Dynamics,INc. 一 概述和介绍 1.网络应用和SQL注射 1.1概述 有些网络数据库没有过滤客户提供的数据中可能有害的字符，SQL注射就是利用插入有害字符进行攻击的技术。尽管非常容易防范，但因特网上仍然有惊人数量的存储系统容易受到这种攻击。这篇文章的目的是指导专业安全组织了解这种技术，并告诉他们正确的,用来防范SQL注射的办法,以及处理各种常见的,由于非法输入引起的问题. 1.2背景 在读这篇文章之前，你应该对数据库如何工作,以及SQL如何被用来访问数据库有一些基础的了解。我建议您阅读eX的文章“Introduction to Databases for WebDevelopers”。 （网址:/tutorials/sql/toc.html） 1.3字符编码 在大多数的网络浏览器中，标点符号和许多其它符号在用于一个网络请求前需要把URL编码,以便被适当地编译（interpret）。在本文中的例子和截图中我使用了固定的ASCII字符以保证最大的可读性。然而，在实际应用中，你需要在HTTP请求中用%25来代替百分号(%)，用%2B来代替加号(+)等等。。。 2.易损性的测试（Testing for vulnerability） 2.1综合测试 彻底地检测一个网络请求是否容易被SQL注射比一个可能的猜测（might guess）需要耗费更多的精力。当你把一个单引号放进一个脚本的第一个参数值时，服务器返回一个空白的网页，上面除了ODBC错误以外什么都没有.显然这种情况直接反映出web程序存在漏洞，但通常都不是这样的，如果你没有注意细节的话，很容易忽略掉一个看上去完美,其实很脆弱的脚本。 服务器上每一个脚本中的每一个参数都应该被检测。开发者和开发组织之间可能很不一致。设计脚本A的程序员也许和脚本B的开发毫无关系，所以，其中一个也许对SQL注射免疫，而另外一个可能不会。事实上，设计脚本A里的函数A的程序员也许和脚本A里的函数B的开发毫无关系，所以脚本A里的一个参数也许对SQL注射是脆弱的，而另外一个参数却不一定，即使整个网络请求是由一个程序员来构想，设计，编写及测试的，在成千上万的脚本中的参数中，由于某种原因，设计者忘了检验某个地方的数据，所以仍有可能存在一个脆弱的参数，而且那个地方是唯一的，你永远都不能确定是哪里，所以必须测试所有的东西。 2.2测试过程 用一个单引号和一个SQL关键字（比如“WHERE”）替代每一个参数的值（argument），每个参数都应该被单独地测试，不止那样，当你测试一个参数的时候，应该保持其它的参数不变，并用有效的数据填充它们的值（argument），It can be tempting to just delete all of the stuff that youre not working with in order to make things look simpler, particularly with applications that have parameter lines that go into many thousands of characters. 当你测试一个参数是否能被SQL注射的时候，如果忽略了其它参数或者给他们一个错误的值（argument），网络请求就有可能由于其它原因而出错，这阻碍了你判断SQL注射是否可行。比如，让我们假设以下是一个有效的，纯粹的（unaltered）参数行: ContactName=Maria%20AndersCompanyName=Alfreds%20Futterkiste 并且它返回一个ODBC错误: ContactName=Maria%20AndersCompanyName=%20OR 如果我们这样检测: CompanyName= 可能只会给你一个错误告诉你需要指定一个Contac