一、 注入式攻擊的類型可能存在許多不同類型的攻擊動(dòng)機(jī)，但是乍看上去，似乎存在更多的類型。這是非常真實(shí)的-如果惡意用戶發(fā)現(xiàn)了一個(gè)能夠執(zhí)行多個(gè)查詢的辦法的話。本文后面，我們會(huì)對(duì)此作詳細(xì)討論。

如果你的腳本正在執(zhí)行一個(gè)SELECT指令，那么，攻擊者可以強(qiáng)迫顯示一個(gè)表格中的每一行記錄-通過(guò)把一個(gè)例如'1=1'這樣的條件注入到WHERE子句中，如下所示：

SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'

正如我們?cè)谇懊嫠懻摰?，這本身可能是很有用的信息，因?yàn)樗沂玖嗽摫砀竦囊话憬Y(jié)構(gòu)(這是一條普通的記錄所不能實(shí)現(xiàn)的)，以及潛在地顯示包含機(jī)密信息的記錄。

一條更新指令潛在地具有更直接的威脅。通過(guò)把其它屬性放到SET子句中，一名攻擊者可以修改當(dāng)前被更新的記錄中的任何字段，例如下面的例子：

UPDATE wines SET type='red'，'vintage'='9999' WHERE variety = 'lagrein'

通過(guò)把一個(gè)例如1=1這樣的恒真條件添加到一條更新指令的WHERE子句中，這種修改范圍可以擴(kuò)展到每一條記錄，例如下面的例子：

UPDATE wines SET type='red'，'vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'

最危險(xiǎn)的指令可能是DELETE-這是不難想像的。其注入技術(shù)與我們已經(jīng)看到的相同-通過(guò)修改WHERE子句來(lái)擴(kuò)展受影響的記錄的范圍，例如下面的例子：

DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'

二、 多個(gè)查詢注入

多個(gè)查詢注入將會(huì)加劇一個(gè)攻擊者可能引起的潛在的損壞-通過(guò)允許多條破壞性指令包括在一個(gè)查詢中。在使用MySQL數(shù)據(jù)庫(kù)時(shí)，攻擊者通過(guò)把一個(gè)出乎意料之外的終止符插入到查詢中即可很容易實(shí)現(xiàn)這一點(diǎn)-此時(shí)一個(gè)注入的引號(hào)(單引號(hào)或雙引號(hào))標(biāo)記期望變量的結(jié)尾;然后使用一個(gè)分號(hào)終止該指令?，F(xiàn)在，一個(gè)另外的攻擊指令可能被添加到現(xiàn)在終止的原始指令的結(jié)尾。最終的破壞性查詢可能看起來(lái)如下所示：

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è)簡(jiǎn)單的SELECT語(yǔ)句中。如果你遵循我們?cè)谝郧拔恼轮械慕ㄗh-嚴(yán)格限制該過(guò)程用戶的特權(quán)，那么，這應(yīng)該無(wú)法工作，因?yàn)閣eb服務(wù)器守護(hù)程序不再擁有你撤回的GRANT特權(quán)。但是從理論上講，這樣的一個(gè)攻擊可能給予BadGuy自由權(quán)力來(lái)實(shí)現(xiàn)他對(duì)你的數(shù)據(jù)庫(kù)的任何操作。

至于這樣的一個(gè)多查詢是否會(huì)被MySQL服務(wù)器處理，結(jié)論并不唯一。這其中的一些原因可能是由于不同版本的MySQL所致，但是大多數(shù)情況卻是由于多查詢存在的方式所致。MySQL的監(jiān)視程序完全允許這樣的一個(gè)查詢。常用的MySQL GUI-phpMyAdmin，在最終查詢之前會(huì)復(fù)制出以前所有的內(nèi)容，并且僅僅這樣做。

但是，大多數(shù)的在一個(gè)注入上下文中的多查詢都是由PHP的mysql擴(kuò)展負(fù)責(zé)管理的。幸好，默認(rèn)情況下，它是不允許在一個(gè)查詢中執(zhí)行多個(gè)指令的;試圖執(zhí)行兩個(gè)指令(例如上面所示的注入)將會(huì)簡(jiǎn)單地導(dǎo)致失敗-不設(shè)置任何錯(cuò)誤，并且沒(méi)有生成任何輸出信息。在這種情況下，盡管PHP也只是'規(guī)規(guī)矩矩'地實(shí)現(xiàn)其缺省行為，但是確實(shí)能夠保護(hù)你免于大多數(shù)簡(jiǎn)單的注入式攻擊。

PHP5中的新的mysqli擴(kuò)展(參考http://php.net/mysqli)，就象mysql一樣，內(nèi)在地也不支持多個(gè)查詢，不過(guò)卻提供了一個(gè)mysqli_multi_query()函數(shù)以支持你實(shí)現(xiàn)多查詢-如果你確實(shí)想這樣做的話。

然而，對(duì)于SQLite-與PHP5綁定到一起的可嵌入的SQL數(shù)據(jù)庫(kù)引擎(參考http://sqlite.org/和http://php.net/sqlite)情況更為可怕，由于其易于使用而吸引了大量用戶的關(guān)注。在有些情況下，SQLite缺省地允許這樣的多指令查詢，因?yàn)樵摂?shù)據(jù)庫(kù)可以優(yōu)化批查詢，特別是非常有效的批INSERT語(yǔ)句處理。然而，如果查詢的結(jié)果為你的腳本所使用的話(例如在使用一個(gè)SELECT語(yǔ)句檢索記錄的情況下)，sqlite_query()函數(shù)卻不會(huì)允許執(zhí)行多個(gè)查詢。

三、 INVISION Power BOARD SQL注入脆弱性

Invision Power Board是一個(gè)著名的論壇系統(tǒng)。2005年五月6號(hào)，在登錄代碼中發(fā)現(xiàn)了一處SQL注入脆弱性。其發(fā)現(xiàn)者為GulfTech Security Research的James Bercegay。

這個(gè)登錄查詢?nèi)缦滤荆?/P>

$DB->query('SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'');

其中，成員ID變量$mid和口令I(lǐng)D變量$pid被使用下面兩行代碼從my_cookie()函數(shù)中檢索出：

$mid = intval($std->my_getcookie('member_id'));$pid = $std->my_getcookie('pass_hash');

在此，my_cookie()函數(shù)使用下列語(yǔ)句從cookie中檢索要求的變量：

return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);

【注意】從該cookie返回的值根本沒(méi)有被處理。盡管$mid在使用于查詢之前被強(qiáng)制轉(zhuǎn)換成一個(gè)整數(shù)，但是$pid卻保持不變。因此，它很容易遭受我們前面所討論的注入類型的攻擊。

因此，通過(guò)以如下方式修改my_cookie()函數(shù)，這種脆弱性就會(huì)暴露出來(lái)：

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)過(guò)這樣的改正之后，其中的關(guān)鍵變量在'通過(guò)'全局clean_value()函數(shù)后被返回，而其它變量卻未進(jìn)行檢查。

現(xiàn)在，既然我們大致了解了什么是SQL注入，它的注入原理以及這種注入的脆弱程度，那么接下來(lái)，讓我們探討如何有效地預(yù)防它。幸好，PHP為我們提供了豐富的資源，因此我們有充分的信心預(yù)言，一個(gè)經(jīng)仔細(xì)地徹底地使用我們所推薦的技術(shù)構(gòu)建的應(yīng)用程序?qū)?huì)從你的腳本中根本上消除任何可能性的SQL注入-通過(guò)在它可能造成任何損壞之前'清理'你的用戶的數(shù)據(jù)來(lái)實(shí)現(xiàn)。

四、 界定你的查詢中的每一個(gè)值

我們推薦，你確保界定了你的查詢中的每一個(gè)值。字符串值首當(dāng)其沖，以及那些你通常期望應(yīng)該使用'單'(而不是'雙')引號(hào)的內(nèi)容。一方面，如果你使用雙引號(hào)來(lái)允許PHP在字符串內(nèi)的變量替代，這樣可以使得輸入查詢更為容易些;另一方面，這(無(wú)可否認(rèn)，只是極少量地)也會(huì)減少以后PHP代碼的分析工作。

下面，讓我們使用我們一開始使用的那個(gè)非注入式查詢來(lái)說(shuō)明這個(gè)問(wèn)題：

SELECT * FROM wines WHERE variety = 'lagrein'

或以PHP語(yǔ)句表達(dá)為：

$query = 'SELECT * FROM wines WHERE variety = '$variety'';

從技術(shù)上講，引號(hào)對(duì)于數(shù)字值來(lái)說(shuō)是不需要使用的。但是，如果你并不介意用引號(hào)把例如葡萄酒這樣的一個(gè)域相應(yīng)的一個(gè)值括起來(lái)并且如果你的用戶把一個(gè)空值輸入到你的表單中的話，那么，你會(huì)看到一個(gè)類似下面的查詢：

SELECT * FROM wines WHERE vintage =

當(dāng)然，這個(gè)查詢從語(yǔ)法上講是無(wú)效的;但是，下面的語(yǔ)法卻是有效的：

SELECT * FROM wines WHERE vintage = ''

第二個(gè)查詢將(大概)不會(huì)返回任何果，但是至少它不會(huì)返回一個(gè)錯(cuò)誤消息。

五、 檢查用戶提交的值的類型

從前面的討論中我們看到，迄今為止，SQL注入的主要來(lái)源往往出在一個(gè)意料之外的表單入口上。然而，當(dāng)你經(jīng)由一個(gè)表單向用戶提供機(jī)會(huì)提交某些值時(shí)，你應(yīng)該有相當(dāng)?shù)膬?yōu)勢(shì)來(lái)確定你想取得什么樣的輸入內(nèi)容-這可以使得我們比較容易地檢查用戶入口的有效性。在以前的文章中，我們已經(jīng)討論過(guò)這樣的校驗(yàn)問(wèn)題;所以，在此，我們僅簡(jiǎn)單地總結(jié)當(dāng)時(shí)我們討論的要點(diǎn)。如果你正在期望一個(gè)數(shù)字，那么你可以使用下面這些技術(shù)之一來(lái)確保你得到的真正是一個(gè)數(shù)字類型：

· 使用is_int()函數(shù)(或is_integer()或is_long())。

· 使用gettype()函數(shù)。

· 使用intval()函數(shù)。

· 使用settype()函數(shù)。

為了檢查用戶輸入內(nèi)容的長(zhǎng)度，你可以使用strlen()函數(shù)。為了檢查一個(gè)期望的時(shí)間或日期是否有效，你可以使用strtotime()函數(shù)。它幾乎一定能夠確保一位用戶的入口中沒(méi)有包含分號(hào)字符(除非標(biāo)點(diǎn)符號(hào)可以被合法地包括在內(nèi))。你可以借助于strpos()函數(shù)容易地實(shí)現(xiàn)這一點(diǎn)，如下所示：

if( strpos( $variety， ';' ) ) exit ( '$variety is an invalid value for variety!' );

正如我們?cè)谇懊嫠岬降?，只要你仔?xì)分析你的用戶輸入期望，那么，你應(yīng)該能夠很容易地檢查出其中存在的許多問(wèn)題。

六、 從你的查詢中濾去每一個(gè)可疑字符

盡管在以前的文章中，我們已經(jīng)討論過(guò)如何過(guò)濾掉危險(xiǎn)字符的問(wèn)題;但是在此，還是讓我們?cè)俅魏?jiǎn)單地強(qiáng)調(diào)并歸納一下這個(gè)問(wèn)題：

· 不要使用magic_quotes_gpc指令或它的'幕后搭擋'-addslashes()函數(shù)，此函數(shù)在應(yīng)用程序開發(fā)中是被限制使用的，并且此函數(shù)還要求使用額外的步驟-使用stripslashes()函數(shù)。

· 相比之下，mysql_real_escape_string()函數(shù)更為常用，但是也有它自己的缺點(diǎn)。