- 相關(guān)推薦
了解常見(jiàn)的php中sql注入式攻擊
在php開(kāi)發(fā)網(wǎng)站的過(guò)程中，經(jīng)常會(huì )遇到各種類(lèi)型的攻擊，比如注入式攻擊、多個(gè)查詢(xún)的注入攻擊等。
一、 注入式攻擊
當腳本正在執行一個(gè)SELECT指令，攻擊者便可以強迫顯示一個(gè)表格中的每一行記錄-通過(guò)把一個(gè)例如"1=1"這樣的條件注入到WHERE子句中，如下所示：
復制代碼 代碼示例:
SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'
這本身可能是很有用的信息，因為它揭示了該表格的一般結構(這是一條普通的記錄所不能實(shí)現的)，以及潛在地顯示包含機密信息的記錄。
一條更新指令潛在地具有更直接的威脅。通過(guò)把其它屬性放到SET子句中，一名攻擊者可以修改當前被更新的記錄中的任何字段，例如下面的例子：
復制代碼 代碼示例:
UPDATE wines SET type='red'，'vintage'='9999' WHERE variety = 'lagrein'
通過(guò)把一個(gè)例如1=1這樣的恒真條件添加到一條更新指令的WHERE子句中，這種修改范圍可以擴展到每一條記錄，例如下面的例子：
復制代碼 代碼示例:
UPDATE wines SET type='red'，'vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'
最危險的指令可能是DELETE-這是不難想像的。其注入技術(shù)與我們已經(jīng)看到的相同-通過(guò)修改WHERE子句來(lái)擴展受影響的記錄的范圍，例如下面的例子：
復制代碼 代碼示例:
DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'
二、 多個(gè)查詢(xún)注入
多個(gè)查詢(xún)注入將會(huì )加劇一個(gè)攻擊者可能引起的潛在的損壞-通過(guò)允許多條破壞性指令包括在一個(gè)查詢(xún)中。在使用MySQL數據庫時(shí)，攻擊者通過(guò)把一個(gè)出乎意料之外的終止符插入到查詢(xún)中即可很容易實(shí)現這一點(diǎn)-此時(shí)一個(gè)注入的引號(單引號或雙引號)標記期望變量的結尾；然后使用一個(gè)分號終止該指令�，F在，一個(gè)另外的攻擊指令可能被添加到現在終止的原始指令的結尾。最終的破壞性查詢(xún)可能看起來(lái)如下所示：
復制代碼 代碼示例:
SELECT * FROM wines WHERE variety = 'lagrein';GRANT ALL ON *.* TO 'BadGuy@%' IDENTIFIED BY 'gotcha';'
這個(gè)注入將創(chuàng )建一個(gè)新的用戶(hù)BadGuy并賦予其網(wǎng)絡(luò )特權（在所有的表格上具有所有的特權）；其中，還有一個(gè)"不祥"的口令被加入到這個(gè)簡(jiǎn)單的 SELECT語(yǔ)句中。如果你遵循我們在以前文章中的建議－嚴格限制該過(guò)程用戶(hù)的特權，那么，這應該無(wú)法工作，因為Web服務(wù)器守護程序不再擁有你撤回的 GRANT特權。但是從理論上講，這樣的一個(gè)攻擊可能給予BadGuy自由權力來(lái)實(shí)現他對你的數據庫的任何操作。
至于這樣的一個(gè)多查詢(xún)是否會(huì )被MySQL服務(wù)器處理，結論并不唯一。這其中的一些原因可能是由于不同版本的MySQL所致，但是大多數情況卻是由于多查詢(xún)存在的方式所致。 MySQL的監視程序完全允許這樣的一個(gè)查詢(xún)。常用的MySQL GUI-phpMyAdmin，在最終查詢(xún)之前會(huì )復制出以前所有的內容，并且僅僅這樣做。
但是，大多數的在一個(gè)注入上下文中的多查詢(xún)都是由PHP的mysql擴展負責管理的。幸好，默認情況下，它是不允許在一個(gè)查詢(xún)中執行多個(gè)指令的；試圖執行兩個(gè)指令(例如上面所示的注入)將會(huì )簡(jiǎn)單地導致失敗-不設置任何錯誤，并且沒(méi)有生成任何輸出信息。在這種情況下，盡管PHP也只是"規規矩矩"地實(shí)現其缺省行為，但是確實(shí)能夠保護你免于大多數簡(jiǎn)單的注入式攻擊。
PHP5中的新的mysqli擴展(參考http://php.net/mysqli)，就象mysql一樣，內在地也不支持多個(gè)查詢(xún)，不過(guò)卻提供了一個(gè)mysqli_multi_query()函數以支持你實(shí)現多查詢(xún)-如果你確實(shí)想這樣做的話(huà)。
然而，對于SQLite-與PHP5綁定到一起的可嵌入的SQL數據庫引擎(參考http://sqlite.org/和http: //php.net/sqlite)情況更為可怕，由于其易于使用而吸引了大量用戶(hù)的關(guān)注。在有些情況下，SQLite缺省地允許這樣的多指令查詢(xún)，因為該數據庫可以?xún)?yōu)化批查詢(xún)，特別是非常有效的批INSERT語(yǔ)句處理。然而，如果查詢(xún)的結果為你的腳本所使用的話(huà)（例如在使用一個(gè)SELECT語(yǔ)句檢索記錄的情況下），sqlite_query()函數卻不會(huì )允許執行多個(gè)查詢(xún)。
三、 INVISION Power BOARD SQL注入脆弱性
下面是一個(gè)著(zhù)名的論壇系統在登錄代碼中發(fā)現的一處SQL注入脆弱性。
這個(gè)登錄查詢(xún)如下所示：
復制代碼 代碼示例:
$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");
其中，成員ID變量$mid和口令I(lǐng)D變量$pid被使用下面兩行代碼從my_cookie()函數中檢索出：
復制代碼 代碼示例:
$mid = intval($std->my_getcookie('member_id'));$pid = $std->my_getcookie('pass_hash');
在此，my_cookie()函數使用下列語(yǔ)句從cookie中檢索要求的變量：
復制代碼 代碼示例:
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
注意：從該cookie返回的值根本沒(méi)有被處理。盡管$mid在使用于查詢(xún)之前被強制轉換成一個(gè)整數，但是$pid卻保持不變。因此，它很容易遭受我們前面所討論的注入類(lèi)型的攻擊。
因此，通過(guò)以如下方式修改my_cookie()函數，這種脆弱性就會(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()函數后被返回，而其它變量卻未進(jìn)行檢查。
【了解常見(jiàn)的php中sql注入式攻擊】相關(guān)文章：
在PHP中阻止SQL注入式攻擊的方法09-07
在PHP中全面阻止SQL注入式攻擊的方法05-14
PHP阻止SQL注入式攻擊的方法08-27
php中sql注入與XSS攻擊的介紹11-10
php防止SQL注入攻擊與XSS攻擊方法08-07
關(guān)于php中sql注入與XSS攻擊的相關(guān)介紹07-04
php中防止SQL注入的方法06-16