如何對PHP程式中的常見漏洞進行攻擊（上）第1/2頁_PHP教學

之所以翻譯這篇文章，是因為目前關於CGI安全性的文章都是拿Perl當例子，而專門介紹ASP，PHP或JSP安全性的文章則很少。 Shaun Clowes的這篇文章比較全面地介紹了PHP的安全問題，原文可以在http: //www.securereality.com.au/studyinscarlet.txt找到。 

由於原文比較長，而且有相當一部分是介紹文章的背景或PHP的基礎知識，沒有涉及到PHP安全方面的內容，因此我沒有翻譯。如果你想了解這方面的知識，請參考原文。

文章主要從全局變量，遠端文件，文件上載，庫文件，Session文件，數據類型和容易出錯的函數這幾個方面分析了PHP的安全性，並且對如何增強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"; 
?> 

上面的程式碼是否先檢查使用者的密碼是否為「每個使用者的程式碼”，如果符合的話，則設定“$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”，如果失敗就顯示錯誤訊息。的特性，那就是它可以從任何其它WEB或FTP站點讀取文件。 「$filename」為「http://target/scripts/..� ../winnt/system32/cmd.exe?/c dir」 
則上面的程式碼其實是利用主機target上的unicode漏洞，執行了dir命令。的內容，並且把它們按照PHP程式碼解釋，主要用在函式庫文件上。 🎜>?> 

上 例中「$libdir」一般是一個在執行程式碼前已經設定好的路徑，如果攻擊者能夠使得「$libdir」沒有被設定的話，那麼他就可以改變這個路徑。支持，攻擊者就可以做任何事情。 /etc"); 
?> 

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

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

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

 
 
 
 

 

上 面的程式碼讓使用者從本地機器選擇一個文件，當點擊提交後，文件就會被點擊提交後，文件就會被點擊上載到伺服器。這顯然很有用的功能，但是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") file (e.g 1024) 
$hello_name = The original name of the file on the remote system (e.g .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））： 

$hello = "/etc/passwd" 
$hello_size = 10240 
$hello_type/po" 🎜>$hello_name = "hello.txt" 

上面的表單資料正好滿足了PHP程式所期望的變量，但是這時PHP程式不再處理上載的文件，而是處理「/etc/passwd 」（通常會導致內容暴露）。這種攻擊可以用於暴露任何敏感文件的內容。

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

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

if (file_exists($theme)) // Checks the (file_exists($theme)) // Checks the on the local system (no remote files) 
include("$theme"); 
?> 

如 果theme」來讀取遠端系統上的任何檔案。攻擊者的最終目標是在遠端伺服器上執行任意指令， 但是他無法使用遠端文件，因此，他必須得在遠端伺服器上建立一個PHP檔案。這乍看看起來好像是不可能的，但是文件上載幫了我們這個忙，如果攻擊者先在本地 機器上創建一個包含PHP代碼的文件，然後創建一個包含名為“theme”的文件域的表單，最後用這個表單透過文件上載把創建的包含PHP程式碼的文件提交 給上面的程式碼，PHP就會把攻擊者提交的文件保存起來，並把「$theme」的值設定為攻擊者提交的文件，這樣file_exists()函數會檢查通 過，攻擊者的程式碼也會執行。 

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

http://www.bkjia.com/PHPjc/317393.html

www.bkjia.comtruehttp: //www.bkjia.com/PHPjc/317393.htmlTechArticle之所以翻譯這篇文章，是因為目前關於CGI安全性的文章都是拿Perl作為例子，而專門介紹ASP，PHP或JSP安全性的文章則很少。 ShaunClowes的這篇...