關於allow_url_fopen的設定與伺服器的安全--不理解
阿新 • • 發佈：2019-01-20
allow_url_fopen與安全以及PHP libcurl
allow_url_fopen=ON常常會給伺服器和管理員帶來麻煩，但是經常性（至少我這樣認為）的我們需要遠端讀取某個東西，如果設定allow_url_fopen=OFF將其關閉，我們就沒有辦法遠端讀取。
幸好我們有一個很好的PHP模組--curl。下面我就以一個例子說說我用curl遠端讀取的方法：
第一，allow_url_fopen=ON的情況下：
<?php
$str = file_get_contents("http://www.csdn.net/");
if ($str !== false) {
// do something with the content
echo $str;
}
?>
第二，allow_url_fopen = Off的情況下：
<?php
$ch = curl_init("http://www.csdn.net/");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$str = curl_exec($ch);
if ($str !== false) {
// do something with the content
echo $str;
}
curl_close($ch);
?>
如何對PHP程式中的常見漏洞進行攻擊
正如我們前面討論的那樣，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()：把整個檔案內容讀到一個數組中
譯者注：其實這份列表還不是很全，比如“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”
這個選項可以禁止遠端檔案功能，極力推薦！
有的採集功能需要allow_url_fopen為on，而伺服器供應商卻因為不安全而關閉，導致不能採集。
allow_url_fopen=ON常常會給伺服器和管理員帶來麻煩，但是經常性（至少我這樣認為）的我們需要遠端讀取某個東西，如果設定allow_url_fopen=OFF將其關閉，我們就沒有辦法遠端讀取。
幸好我們有一個很好的PHP模組--curl。下面我就以一個例子說說我用curl遠端讀取的方法：
第一，allow_url_fopen=ON的情況下：
<?php
$str = file_get_contents("http://www.csdn.net/");
if ($str !== false) {
// do something with the content
echo $str;
}
?>
第二，allow_url_fopen = Off的情況下：
<?php
$ch = curl_init("http://www.csdn.net/");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$str = curl_exec($ch);
if ($str !== false) {
// do something with the content
echo $str;
}
curl_close($ch);
?>
如何對PHP程式中的常見漏洞進行攻擊
正如我們前面討論的那樣，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()：把整個檔案內容讀到一個數組中
譯者注：其實這份列表還不是很全，比如“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”
這個選項可以禁止遠端檔案功能，極力推薦！
有的採集功能需要allow_url_fopen為on，而伺服器供應商卻因為不安全而關閉，導致不能採集。