|
摘 要 自进入2008年以来，网络界经受了前所未有的SQL注入式攻击，这些网站的页面被修改、数据库被删除或程序被植入恶意代码。给这些网站带来巨大的损失。本文结合多年的网站程序设计与维护的经验来谈谈SQL注入式攻击的一般原理、注入方法及防范措施。
关键字SQL，注入，攻击，方法，防范，安全
近来，当打开网站，查看网页新闻时，会看到一系列有关SQL注入攻击的新闻：
1月，自动SQL注入攻击了超过70,000个美国网站。
4月，F-Secure表示其发现超过五十万网页都被恶意JavaScript代码攻击。
7月，索尼游戏机PlayStation(PS)的美国网站遭到SQL注入攻击。
10月，Adobe旗下网站遭受SQL注入攻击。
…
可见，SQL注入攻击的危害十分巨大。但SQL注入攻击也不是洪水猛兽，只要在开发Web程序时多加防范，就可以减少SQL注入攻击的威胁。本文从原理上分析实现SQL注入的一般方法，并根据这些方法提出相应的防范措施，为Web程序的开发提供一些帮助。
一、SQL注入原理
据统计，目前国内80%以上的网站都是采用Web动态网页结合后台数据库架设而成的。网页先从用户的请求中得到某些参数，然后动态地生成SQL语句请求发送给数据库，再把从数据库中得到的结果返回给网页，从而完成网页执行的功能。
然而，在许多Web网站系统开发过程中，由于程序员编写的代码没有对用户输入数据的合法性进行判断，造成应用程序存在安全隐患。恶意攻击者可以利用用户可提交或可修改的数据，构造出特殊目的SQL语句，并将其插入到系统实际执行的SQL语句中，从而随意获取数据库中的重要信息（如管理员用户名和密码等），修改、添加和删除数据库，甚至控制整个网站服务器。这就是所谓的SQL Injection，即SQL注入式攻击，简称SQL注入。
简单地说，所谓SQL注入漏洞就是用户可提交构造特殊的SQL语句并得到执行的情形。所谓SQL注入攻击，就是利用SQL注入漏洞，非法获取数据库信息，或者入侵网站服务器的行为。
安全专家提示：SQL注入是从正常的WWW端口进行访问网站，表面上看跟一般的Web页面访问没什么区别，所以目前市面上的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会察觉，从而造成数据的泄漏，给网站带来巨大损失。并且随着Web2.0功能得到增强，SQL注入漏洞的风险也随之加大，黑客也在不断优化他们的攻击手段和工具。
二、SQL注入方法
1.收集程序及服务器信息。
在没有设置防注入的网站中，可以通过默认链接正常打开新的页面(测试地址：.../test1/news/show.asp?id=78)，但是在这个地址后面加上单引号“'”，服务器将会返回下面的错误提示：
Microsoft JET Database Engine 错误 '80040e14'
字符串的语法错误 在查询表达式 'ID = 78'' 中。
/news/shown.asp，行 6
通过这个错误提示，能获取以下几点信息：
(1).该网站使用的是Access数据库，通过JET引擎连接数据库，而不是通过ODBC。
(2).程序没有判断客户端提交的数据是否符合程序要求。
(3).该SQL语句所查询的表中有一名为ID的字段。
根据这些提示信息，就可以进一步进行SQL注入测试。
2．获取后继页面信息
在ASP程序中，往往利用querystring参数进行不同页面之间的数据传递，在要打开新的链接时，ASP服务器先从URL中提取出querystring参数中的ID值，然后根据ID值动态生成后继页面。如有以下代码：
ID = Request("ID")
SQL = "Select * From news Where Id=" & ID
Set RS = Server.CreateObject("ADODB.Recordset")
RS.Open SQL, "DSN=..."
Do While Not RS.EOF
Response.Write RS("Content")
Rs.MoveNext
Loop
Set RS = Nothin
在一般情况下，此ASP脚本能够显示具有特定ID值的文章的内容（ .../test1 /news/shown.asp?ID=78），而 ID 值是由URL中的 querystring 参数指定的。然而此段代码存在SQL注入攻击漏洞。某些恶意用户可以把querystring中的ID值偷换为“78 or 1=1”，则原URL变为：.../test1/news/shown.asp?ID=78 or 1=1，从而诱使ASP脚本生成不安全的SQL指令如下：
Select * From news Where ID=0 or 1=1
因1=1永远成立，所以原SQL指令等效为：
Select * From news
于是，数据库将会返回所有文章的内容。
当然，本例中服务器所受的攻击只是文章信息的泄漏，并不会引起很严重后果。但是，如果攻击者用同样的手段发送DELETE等SQL指令有可能把表里的内容全部删除。
3．非法成功提交表单
SQL注入攻击除了可以通过URL实现外，还可以通过页面中的表单实现，而且通过表单提交的SQL注入攻击在方式上更加灵活，危害也更大。
比如在设计用户登录页面时，正常的做法是在登录页面中设计一表单，要求用户在表单中提交用户名（UserName）和密码（PassWord）,只有当用户名和密码均正确时才能通过验证。
假定有两个页面：一个登录页面 (.../test1/userlogin/index.asp) 用于登录，另一个审核页面(.../test1/userlogin/Logincheck.asp) 用于验证用户权限(即向数据库查询用户名/密码组合是否存在)。
(1).登录页面
<form action=" Logincheck.asp " method="post">
Username: <input type="text" name="Username"><br>
Password: <input type="password" name="Password"><br>
<input type="submit"> </form>
(2).审核页面
User = Request ("Username")
Psd = Request ("Password")
SQL = "Select * From Users Where Username='" & User & "' and Password='" & Psd & "'"
Set RS = Server.CreateObject("ADODB.Recordset")
RS.Open SQL, "DSN=..."
If (RS.EOF) Then
Response. .Redirect "Admin.asp"
Else
Response.Redirect "Err.asp"
End If
Set RS = Nothing
初看，审核页面的代码似乎没有任何安全漏洞，因为用户如果不给出有效的用户名／密码组合就无法登录。然而，正是这段代码成了SQL注入攻击的理想目标。攻击者可以在表单的用户名或密码栏中输入包含“or”和“=”等的特殊字符，于是，提交给数据库的SQL指令就可能变成：
SQL = "Select * From Users Where Username=* or 1=1 and Password =* or 1=1
根据前述，可以知道，SQL 服务器将返回包含Users表格中的所有记录的记录集，但在此处设计者往往不会设计循环查询，所以ASP脚本将会以Users表中的第一条记录的身份允许其登录网站，而在很多网站中的第一条记录的用户名往往就是admin！因此，登录后你便可以管理整个网站的资源。即在不知道用户名和密码的情况下，服务器通过验证。从而绕过服务器的条件审查而非法登录网站，实现SQL注入。
例如：在网站的后台管理用户登录时(测试地址：.../test1/userlogin/index.asp)，将字符串“a' or 1=1 or '1”作为用户名和密码提交则成功绕过密码审核而直接登录。
三、SQL注入防范
为了防止SQL注入造成数据泄漏，可以采用相应的措施来加强网站的安全。
1.关闭错误信息提示
如在第一例中，只要在服务器上的IIS管理器中做如下设置，右击站点，在弹出的菜单中选择［属性］，在弹出的对话框的［主目录］选项卡中单击［配置］，在［应用程序配置］对话框的［调试］选项卡中的“脚本错误的错误信息”选项中选择“向客户端发送下列文本错误消息（T）：”并可设置简单的文本提示，也可以使用默认的提示文本。这时，别人就无法通过ASP的错误信息来获得有关服务器及数据库等的相关信息了。
2.防止通过URL注入
对通过querystring参数进行传递ID时，根据ID是数字的特性，可以把querystring参数进行限定：一是限定为数字字符(函数：IsNumeric)，二是限定长度。如果可以预见最大的记录数（假定为9999），那么就可以把querystring参数的长度限定在4位。
对于需在不同页面间进行传送用户名、密码及权限等其它信息时，则不建议采用querystring参数在URL中显式传送，而应该采用Cookif或Session进行隐式传送。另外，Session数据是不写入本地硬盘的，随网页的关闭而失效，因此安全性上高于Cookie。
3.防止构造非法SQL命令
在网站中数据的提交往往是通过表单来进行的，对于用户名、密码，可以指定用户所使用的字符集及字符串长度。但对于文章就无法指定用户所使用的字符集及字符串长度了。
可以使用替换法替换掉一些特定的字符，使这些字符在HTML的页面中可以正常显示，但在SQL命令中却无法识别。如：
if not isnull(HtmlStr) then
HtmlStr = replace(HtmlStr, ">", ">")
HtmlStr = replace(HtmlStr, "<", "<")
HtmlStr = Replace(HtmlStr, CHR(32), "<I></I> ")
HtmlStr = Replace(HtmlStr, CHR(9), " ")
HtmlStr = Replace(HtmlStr, CHR(34), """)
HtmlStr = Replace(HtmlStr, CHR(39), "'")
HtmlStr = Replace(HtmlStr, CHR(13), "")
HtmlStr = Replace(HtmlStr, CHR(10) & CHR(10), "</P><P> ")
HtmlStr = Replace(HtmlStr, CHR(10), "<BR> ")
HTMLcode = HtmlStr
end if
4.杜绝SQL注入
在数据库连接文件中加入防注入代码，在连接数据库文件之前就对一些特定的字符或字符串进行拦截。
HTTP中的请求一般是通过get或者post来发送的，所以只要过滤掉get或者post请求参数信息中所有的非法字符即可。
(1). 定义非法字符串
首先，要定义请求中不能包含字符串，各个字符串用"|"隔开：
dim SQL_injdata
SQL_injdata = "|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare"
SQL_inj = split(SQL_Injdata,"|")
(2).get的拦截：
If Request.QueryString＜＞"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))＞0 Then
Response.Write "＜Script Language=”javascript”＞alert(SQL防注入系统提示↓nn请不要在参数中包含非法字符尝试注入！);history.back(-1)＜/Script＞"
Response.end
end if
next
Next
end if
(3).plst的拦截
实现了get请求的注入拦截后，可以用同样的方法来实现post请求的注入拦截。要做的只是把字符串Request.QueryString替换成Request.Form，以及将字符串get替换成post即可。
通过以上代码，就可以实现get和post请求的非法信息拦截，减少受到SQL注入攻击的危险。
四、结语
通过以上几种SQL注入防范措施的综合运用，就能最大限度地杜绝SQL注入攻击的漏洞的产生，让SQL注入攻击无门。
当然，技术永无止境，安全与漏洞就是一对孪生的双胞胎，互相促进与提高。要开发一个安全的Web程序，除尽可能采用先进的Web开发程序外，更关键的是要提高Web程序开发人员防范攻击的意识，避免程序设计过程中的漏洞，给攻击者有可趁之机，提高程序的安全性。
|
