在PHP中全面禁止SQL注进式攻击之一
一、 注进式攻击的类型
可能存在很多不同类型的攻击动机,但是乍看上往,似乎存在更多的类型。这是非常真实的-假如恶意用户发明了一个能够履行多个查询的措施的话。本文后面,我们会对此作具体讨论。
假如你的脚本正在履行一个SELECT指令,那么,攻击者可以逼迫显示一个表格中的每一行记录-通过把一个例如'1=1'这样的条件注进到WHERE子句中,如下所示(其中,注进部分以粗体显示):
SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'
正如我们在前面所讨论的,这本身可能是很有用的信息,由于它揭示了该表格的一般结构(这是一条普通的记录所不能实现的),以及埋伏地显示包含机密信息的记录。
一条更新指令埋伏地具有更直接的要挟。通过把其它属性放到SET子句中,一名攻击者可以修正当前被更新的记录中的任何字段,例如下面的例子(其中,注进部分以粗体显示):
UPDATE wines SET type='red','vintage'='9999' WHERE variety = 'lagrein'
通过把一个例如1=1这样的恒真条件添加到一条更新指令的WHERE子句中,这种修正范畴可以扩大到每一条记录,例如下面的例子(其中,注进部分以粗体显示):
UPDATE wines SET type='red','vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'
最危险的指令可能是DELETE-这是不难想像的。其注进技巧与我们已经看到的雷同-通过修正WHERE子句来扩大受影响的记录的范畴,例如下面的例子(其中,注进部分以粗体显示):
DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'
二、 多个查询注进
多个查询注进将会加剧一个攻击者可能引起的埋伏的损坏-通过答应多条损坏性指令包含在一个查询中。在应用MySQL数据库时,攻击者通过把一个出乎意料之外的终止符插进到查询中即可很轻易实现这一点-此时一个注进的引号(单引号或双引号)标记期看变量的结尾;然后应用一个分号终止该指令。现在,一个另外的攻击指令可能被添加到现在终止的原始指令的结尾。终极的损坏性查询可能看起来如下所示:
SELECT * FROM wines WHERE variety = 'lagrein';
GRANT ALL ON *.* TO 'BadGuy@%' IDENTIFIED BY 'gotcha';'
这个注进将创立一个新的用户BadGuy并赋予其网络特权(在所有的表格上具有所有的特权);其中,还有一个'不祥'的口令被参加到这个简略的SELECT语句中。假如你遵守我们在以前文章中的建议-严格限制该过程用户的特权,那么,这应当无法工作,由于web服务器守护程序不再拥有你撤回的GRANT特权。但是从理论上讲,这样的一个攻击可能给予BadGuy自由权利来实现他对你的数据库的任何把持。
至于这样的一个多查询是否会被MySQL服务器处理,结论并不唯一。这其中的一些原因可能是由于不同版本的MySQL所致,但是大多数情况却是由于多查询存在的方法所致。MySQL的监督程序完整答应这样的一个查询。常用的MySQL GUI-phpMyAdmin,在终极查询之前会复制出以前所有的内容,并且仅仅这样做。
但是,大多数的在一个注进高低文中的多查询都是由PHP的mysql扩大负责治理的。幸好,默认情况下,它是不答应在一个查询中履行多个指令的;试图履行两个指令(例如上面所示的注进)将会简略地导致失败-不设置任何错误,并且没有天生任何输出信息。在这种情况下,尽管PHP也只是'规行矩步'地实现其缺省行动,但是确实能够保护你免于大多数简略的注进式攻击。
PHP5中的新的mysqli扩大(参考http://php.net/mysqli),就象mysql一样,内在地也不支撑多个查询,不过却供给了一个mysqli_multi_query()函数以支撑你实现多查询-假如你确实想这样做的话。
然而,对于SQLite-与PHP5绑定到一起的可嵌进的SQL数据库引擎(参考http://sqlite.org/和http://php.net/sqlite)情况更为可怕,由于其易于应用而吸引了大批用户的关注。在有些情况下,SQLite缺省地答应这样的多指令查询,由于该数据库可以优化批查询,特别是非常有效的批INSERT语句处理。然而,假如查询的成果为你的脚本所应用的话(例如在应用一个SELECT语句检索记录的情况下),sqlite_query()函数却不会答应履行多个查询。
三、 INVISION Power BOARD SQL注进脆弱性
Invision Power Board是一个著名的论坛系统。2005年五月6号,在登录代码中发明了一处SQL注进脆弱性。其发明者为GulfTech Security Research的James Bercegay。
这个登录查询如下所示:
$DB->query('SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'');
其中,成员ID变量$mid和口令ID变量$pid被应用下面两行代码从my_cookie()函数中检索出:
$mid = intval($std->my_getcookie('member_id'));
$pid = $std->my_getcookie('pass_hash');
在此,my_cookie()函数应用下列语句从cookie中检索请求的变量:
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
【留心】从该cookie返回的值基本没有被处理。尽管$mid在应用于查询之前被强迫转换成一个整数,但是$pid却保持不变。因此,它很轻易遭遇我们前面所讨论的注进类型的攻击。
因此,通过以如下方法修正my_cookie()函数,这种脆弱性就会***露出来:
if ( ! in_array( $name,array('topicsread', 'forum_read','collapseprefs') ) )
{
return $this->
clean_value(urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]));
}
else
{
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
}
五、 检查用户提交的值的类型
从前面的讨论中我们看到,迄今为止,SQL注进的重要起源往往出在一个意料之外的表单进口上。然而,当你经过一个表单向用户供给机会提交某些值时,你应当有相当的上风来断定你想取得什么样的输进内容-这可以使得我们比拟轻易地检查用户进口的有效性。在以前的文章中,我们已经讨论过这样的校验标题;所以,在此,我们仅简略地总结当时我们讨论的要点。假如你正在期看一个数字,那么你可以应用下面这些技巧之一来确保你得到的真正是一个数字类型:
· 应用is_int()函数(或is_integer()或is_long())。
· 应用gettype()函数。
· 应用intval()函数。
· 应用settype()函数。
为了检查用户输进内容的长度,你可以应用strlen()函数。为了检查一个期看的时间或日期是否有效,你可以应用strtotime()函数。它几乎必定能够确保一位用户的进口中没有包含分号字符(除非标点符号可以被正当地包含在内)。你可以借助于strpos()函数轻易地实现这一点,如下所示: