SQL概述及在网络安全中的应用（上）

1.网络应用和SQL注射

1.1概述

有些网络数据库没有过滤客户提供的数据中可能有害的字符，SQL注射就是利用插入有害字符进行攻击的技术。尽管非常容易防范，但因特网上仍然有惊人数量的存储系统容易受到这种攻击。这篇文章的目的是指导专业安全组织了解这种技术，并告诉他们正确的,用来防范SQL注射的办法,以及处理各种常见的,由于非法输入引起的问题.

1.2背景

在读这篇文章之前，你应该对数据库如何工作,以及SQL如何被用来访问数据库有一些基础的了解。我建议您阅读eXtropia.com的文章“Introduction to Databases for WebDevelopers”。

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 you're 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%20Anders&CompanyName=Alfreds%20Futterkiste

并且它返回一个ODBC错误:

ContactName=Maria%20Anders&CompanyName='%20OR

如果我们这样检测:

CompanyName='

可能只会给你一个错误告诉你需要指定一个ContactName值。

这行:

ContactName=BadContactName&CompanyName='

可能返回同样的页面，因为请求根本没有指定ContactName。或者，它可能返回你站点默认的主页。或者，可能它找不到指定的ContactName，或者web程序认为没有必要看CompanyName，所以它甚至根本不把这个参数值认为是一个SQL声明，或者，它可能给你一些完全不同的东西,所以，当检测SQL注射的时候，记得总是用完整的参数行，并且除了你正在检测的那个参数外，还要给其它所有的参数一个合法的值。