SQL注入相关数据库知识.doc

SQL注入相关数据库知识 :: 2004-06-03 23:12 一?概述和介绍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=可能只会给你一个错误告诉你需要指定一个ContactName值。这行:ContactName=BadContactNameCompanyName=可能返回同样的页面，因为请求根本没有指定ContactName。或者，它可能返回你站点默认的主页。或者，可能它找不到指定的ContactName，或者web程序认为没有必要看CompanyName，所以它甚至根本不把这个参数值认为是一个SQL声明，或者，它可能给你一些完全不同的东西,所以，当检测SQL注射的时候，记得总是用完整的参数行，并且除了你正在检测的那个参数外，还要给其它所有的参数一个合法的值。2.3分析结果如果你得到一个数据库服务器返回的某些错误信息，那么SQL注射显然是存在的.然而，数据库错误信息不一定总是明显的(有时候编写程序的人可能做一些奇