摘要：在這種狀況下，雖然也只是規(guī)規(guī)矩矩地完成其缺省行為，可是的確能夠維護(hù)你免于大多數(shù)簡略的注入式進(jìn)犯。年五月號，在登錄代碼中發(fā)現(xiàn)了一處注入軟弱性。因而，它很容易遭受咱們前面所評論的注入類型的進(jìn)犯。

或許存在許多不同類型的進(jìn)犯動(dòng)機(jī)，可是乍看上去，好像存在更多的類型。這是十分實(shí)在的-假如歹意用戶發(fā)現(xiàn)了一個(gè)能夠履行多個(gè)查詢的方法的話。
假如你的腳本正在履行一個(gè)SELECT指令，那么，進(jìn)犯者能夠逼迫顯現(xiàn)一個(gè)表格中的每一行記載-經(jīng)過把一個(gè)例如"1=1"這樣的條件注入到WHERE子句中，如下所示(其間，注入部分以粗體顯現(xiàn))：
SELECT * FROM wines WHERE variety = "lagrein" OR 1=1;"
正如咱們在前面所評論的，這自身或許是很有用的信息，由于它揭示了該表格的一般結(jié)構(gòu)(這是一條一般的記載所不能完成的)，以及潛在地顯現(xiàn)包含秘要信息的記載。
一條更新指令潛在地具有更直接的要挾。經(jīng)過把其它特點(diǎn)放到SET子句中，一名進(jìn)犯者能夠修正當(dāng)時(shí)被更新的記載中的任何字段，例如下面的比如（其間，注入部分以粗體顯現(xiàn)）：
UPDATE wines SET type="red"，"vintage"="9999" WHERE variety = "lagrein"
經(jīng)過把一個(gè)例如1=1這樣的恒真條件增加到一條更新指令的WHERE子句中，這種修正規(guī)模能夠擴(kuò)展到每一條記載，例如下面的比如（其間，注入部分以粗體顯現(xiàn)）：
UPDATE wines SET type="red"，"vintage"="9999 WHERE variety = "lagrein" OR 1=1;"
最危險(xiǎn)的指令或許是DELETE-這是不難想像的。其注入技能與咱們現(xiàn)已看到的相同-經(jīng)過修正WHERE子句來擴(kuò)展受影響的記載的規(guī)模，例如下面的比如（其間，注入部分以粗體顯現(xiàn)）：
DELETE FROM wines WHERE variety = "lagrein" OR 1=1;"
二、 多個(gè)查詢注入
多個(gè)查詢注入將會加重一個(gè)進(jìn)犯者或許引起的潛在的損壞-經(jīng)過答應(yīng)多條破壞性指令包含在一個(gè)查詢中。在運(yùn)用MySQL數(shù)據(jù)庫時(shí)，進(jìn)犯者經(jīng)過把一個(gè)出乎意料之外的停止符刺進(jìn)到查詢中即可很容易完成這一點(diǎn)-此刻一個(gè)注入的引號(單引號或雙引號)符號希望變量的結(jié)束；然后運(yùn)用一個(gè)分號停止該指令?，F(xiàn)在，一個(gè)另外的進(jìn)犯指令或許被增加到現(xiàn)在停止的原始指令的結(jié)束。終究的破壞性查詢或許看起來如下所示：
SELECT FROM wines WHERE variety = "lagrein";GRANT ALL ON .* TO "BadGuy@%" IDENTIFIED BY "gotcha";"
這個(gè)注入將創(chuàng)建一個(gè)新的用戶BadGuy并賦予其網(wǎng)絡(luò)特權(quán)（在一切的表格上具有一切的特權(quán)）；其間，還有一個(gè)"不祥"的口令被加入到這個(gè)簡略的 SELECT句子中。假如你遵從咱們在以前文章中的主張－嚴(yán)厲限制該進(jìn)程用戶的特權(quán)，那么，這應(yīng)該無法工作，由于Web服務(wù)器看護(hù)程序不再具有你撤回的 GRANT特權(quán)?？墒菑睦碚撋现v，這樣的一個(gè)進(jìn)犯或許給予BadGuy自在權(quán)利來完成他對你的數(shù)據(jù)庫的任何操作。
至于這樣的一個(gè)多查詢是否會被MySQL服務(wù)器處理，定論并不唯一。這其間的一些原因或許是由于不同版本的MySQL所形成的，可是大多數(shù)狀況卻是由于多查詢存在的方法所形成的。 MySQL的監(jiān)督程序徹底答應(yīng)這樣的一個(gè)查詢。常用的MySQL GUI-phpMyAdmin，在終究查詢之前會復(fù)制出以前一切的內(nèi)容，并且僅僅這樣做。
可是，大多數(shù)的在一個(gè)注入上下文中的多查詢都是由PHP的mysql擴(kuò)展擔(dān)任管理的。幸虧，默許狀況下，它是不答應(yīng)在一個(gè)查詢中履行多個(gè)指令的；企圖履行兩個(gè)指令(例如上面所示的注入)將會簡略地導(dǎo)致失利-不設(shè)置任何錯(cuò)誤，并且沒有生成任何輸出信息。在這種狀況下，雖然PHP也只是"規(guī)規(guī)矩矩"地完成其缺省行為，可是的確能夠維護(hù)你免于大多數(shù)簡略的注入式進(jìn)犯。
PHP5中的新的mysqli擴(kuò)展(參閱http://php.net/mysqli)，就象mysql相同，內(nèi)在地也不支撐多個(gè)查詢，不過卻供給了一個(gè)mysqli_multi_query()函數(shù)以支撐你完成多查詢-假如你的確想這樣做的話。
可是，關(guān)于SQLite-與PHP5綁定到一同的可嵌入的SQL數(shù)據(jù)庫引擎(參閱http://sqlite.org/和http: //php.net/sqlite)狀況更為可怕，由于其易于運(yùn)用而招引了很多用戶的重視。在有些狀況下，SQLite缺省地答應(yīng)這樣的多指令查詢，由于該數(shù)據(jù)庫能夠優(yōu)化批查詢，特別是十分有用的批INSERT句子處理?？墒?，假如查詢的成果為你的腳本所運(yùn)用的話（例如在運(yùn)用一個(gè)SELECT句子檢索記載的狀況下），sqlite_query()函數(shù)卻不會答應(yīng)履行多個(gè)查詢。
三、 INVISION Power BOARD SQL注入軟弱性
Invision Power Board是一個(gè)聞名的論壇體系。2005年五月6號，在登錄代碼中發(fā)現(xiàn)了一處SQL注入軟弱性。其發(fā)現(xiàn)者為GulfTech Security Research的James Bercegay。
這個(gè)登錄查詢?nèi)缦滤荆?br>$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password="$pid"");
其間，成員ID變量$mid和口令I(lǐng)D變量$pid被運(yùn)用下面兩行代碼從my_cookie()函數(shù)中檢索出：
$mid = intval($std->my_getcookie("member_id"));$pid = $std->my_getcookie("pass_hash");
　　在此，my_cookie()函數(shù)運(yùn)用下列句子從cookie中檢索要求的變量：
return urldecode($_cookie[$ibforums->vars["cookie_id"].$name]);
【留意】從該cookie回來的值底子沒有被處理。雖然$mid在運(yùn)用于查詢之前被強(qiáng)制轉(zhuǎn)換成一個(gè)整數(shù)，可是$pid卻保持不變。因而，它很容易遭受咱們前面所評論的注入類型的進(jìn)犯。
　　因而，經(jīng)過以如下方法修正my_cookie()函數(shù)，這種軟弱性就會露出出來：
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]);
}

經(jīng)過這樣的改正之后，其間的要害變量在"經(jīng)過"全局clean_value()函數(shù)后被回來，而其它變量卻未進(jìn)行檢查。
現(xiàn)在，已然咱們大致了解了什么是SQL注入，它的注入原理以及這種注入的軟弱程度，那么接下來，讓咱們探討如何有用地防備它。幸虧，PHP為咱們供給了豐厚的資源，因而咱們有充沛的信心預(yù)言，一個(gè)經(jīng)細(xì)心地徹底地運(yùn)用咱們所引薦的技能構(gòu)建的應(yīng)用程序?qū)哪愕哪_本中底子上消除任何或許性的SQL注入-經(jīng)過在它或許形成任何損壞之前"整理"你的用戶的數(shù)據(jù)來完成。