了解常見的php的sql注入式攻擊

時(shí)間：2025-12-23 06:08:51 php語言

了解常見的php的sql注入式攻擊

　　在php開發(fā)網(wǎng)站的過程中，經(jīng)常會(huì)遇到各種類型的攻擊，比如注入式攻擊、多個(gè)查詢的注入攻擊等。就跟隨百分網(wǎng)小編一起去了解下吧，想了解更多相關(guān)信息請(qǐng)持續(xù)關(guān)注我們應(yīng)屆畢業(yè)生考試網(wǎng)!

　　一、注入式攻擊

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

　　復(fù)制代碼代碼示例:

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

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

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

　　復(fù)制代碼代碼示例:

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

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

　　復(fù)制代碼代碼示例:

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

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

　　復(fù)制代碼代碼示例:

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

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

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

　　復(fù)制代碼代碼示例:

　　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語句中。如果你遵循我們?cè)谝郧拔恼轮械慕ㄗh－嚴(yán)格限制該過程用戶的特權(quán)，那么，這應(yīng)該無法工作，因?yàn)閃eb服務(wù)器守護(hù)程序不再擁有你撤回的 GRANT特權(quán)。但是從理論上講，這樣的一個(gè)攻擊可能給予BadGuy自由權(quán)力來實(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ò)誤，并且沒有生成任何輸出信息。在這種情況下，盡管PHP也只是"規(guī)規(guī)矩矩"地實(shí)現(xiàn)其缺省行為，但是確實(shí)能夠保護(hù)你免于大多數(shù)簡(jiǎn)單的注入式攻擊。

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

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

　　三、 INVISION Power BOARD SQL注入脆弱性

　　下面是一個(gè)著名的論壇系統(tǒng)在登錄代碼中發(fā)現(xiàn)的一處SQL注入脆弱性。

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

　　復(fù)制代碼代碼示例:

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

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

　　復(fù)制代碼代碼示例:

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

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

　　復(fù)制代碼代碼示例:

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

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