或許存在許多不一樣類型的進犯動機，但是乍看上去，好像存在更多的類型。這是十分實在的-假如歹意用戶發現了一個可以履行多個查詢的方法的話。
假如你的腳本正在履行一個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注入-通過在它或許造成任何損壞以前"整理"你的用戶的數據來完成。