或许存在许多不一样类型的进犯动机，但是乍看上去，好像存在更多的类型。这是十分实在的-假如歹意用户发现了一个可以履行多个查询的方法的话。
假如你的脚本正在履行一个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;'
2、 多个查询注入
多个查询注入将会加剧一个进犯者或许引发的潜在的损坏-通过答应多条破坏性指令包含在一个查询中。在运用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()函数却不会答应履行多个查询。
3、 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注入-通过在它或许造成任何损坏以前"整理"你的用户的数据来完成。