PHP中阻撓SQL注入式進犯的方法介紹

這篇文章帶給大家的內容是關於PHP中全面阻撓SQL注入式進犯的方法介紹，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。

或許存在許多不同類型的進犯動機，可是乍看上去，好像存在更多的類型。這是十分實在的-假如歹意用戶發現了一個能夠履行多個查詢的方法的話。

假如你的腳本正在履行一個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;'

#多個查詢注入

多個查詢注入將會加重一個進犯者或許引起的潛在的損壞-經過答應多條破壞性指令包含在一個查詢中。在運用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()函數卻不會答應履行多個查詢。

三、 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注入-经过在它或许形成任何损坏之前"整理"你的用户的数据来完成。

以上是PHP中阻撓SQL注入式進犯的方法介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！