在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]);
}
经过这样的改正之后，其间的要害变量在"经过"全局clean_value()函数后被回来，而其它变量却未进行检查。
现在，已然咱们大致了解了什么是SQL注入，它的注入原理以及这种注入的软弱程度，那么接下来，让咱们探讨如何有用地防备它。幸亏，PHP为咱们供给了丰厚的资源，因而咱们有充沛的信心预言，一个经细心地彻底地运用咱们所引荐的技能构建的应用程序将会从你的脚本中底子上消除任何或许性的SQL注入-经过在它或许形成任何损坏之前"整理"你的用户的数据来完成。