PHP中的安全性知識

時間：2025-08-11 03:44:37 php語言

PHP中的安全性知識

　　導語：安全性也是PHP中的重要部分，下面所討論的安全性環境是在Linux+Apache+Mysql+PHP，一起來學習下吧：

PHP中的安全性知識

　　一、apache server安全性設置

　　1、以Nobody用戶運行

　　一般情況下，Apache是由Root 來安裝和運行的。如果Apache Server進程具有Root用戶特權，那么它將給系統的安全構成很大的威脅，應確保Apache Server進程以最可能低的權限用戶來運行。通過修改httpd.conf文件中的下列選項，以Nobody用戶運行Apache 達到相對安全的目的。

　　User nobody Group# -1

　　2、ServerRoot目錄的權限

　　為了確保所有的配置是適當的和安全的，需要嚴格控制Apache 主目錄的訪問權限，使非超級用戶不能修改該目錄中的內容。Apache 的主目錄對應于Apache Server配置文件httpd.conf的Server Root控制項中，應為：

　　Server Root /usr/local/apache

　　3、SSI的配置

　　在配置文件access.conf 或httpd.conf中的確Options指令處加入Includes NO EXEC選項，用以禁用Apache Server 中的執行功能。避免用戶直接執行Apache 服務器中的執行程序，而造成服務器系統的公開化。

　　Options Includes Noexec

　　4、阻止用戶修改系統設置

　　在Apache 服務器的配置文件中進行以下的設置，阻止用戶建立、修改 .htaccess文件，防止用戶超越能定義的系統安全特性。

　　AllowOveride None Options None Allow from all

　　然后再分別對特定的目錄進行適當的配置。

　　5、改變Apache 服務器的缺省訪問特性

　　Apache 的默認設置只能保障一定程度的安全，如果服務器能夠通過正常的映射規則找到文件，那么客戶端便會獲取該文件，如/pic/~ root/ 將允許用戶訪問整個文件系統。在服務器文件中加入如下內容：

　　order deny,ellow Deny from all

　　將禁止對文件系統的缺省訪問。

　　6、CGI腳本的安全考慮

　　CGI腳本是一系列可以通過Web服務器來運行的程序。為了保證系統的安全性，應確保CGI的作者是可信的。對CGI而言，最好將其限制在一個特定的目錄下，如cgi-bin之下，便于管理;另外應該保證CGI目錄下的文件是不可寫的，避免一些欺騙性的程序駐留或混跡其中;如果能夠給用戶提供一個安全性良好的CGI程序的模塊作為參考，也許會減少許多不必要的麻煩和安全隱患;除去CGI目錄下的所有非業務應用的腳本，以防異常的信息泄漏。

　　7、SSL鏈接加密

　　以上這些常用的舉措可以給Apache Server 一個基本的安全運行環境，顯然在具體實施上還要做進一步的細化分解，制定出符合實際應用的安全配置方案。

　　二、PHP安全性設置

　　服務器并不能阻止所有的安全問題，例如程序漏洞問題、用戶輸入表單問題、PHP文件權限問題等。也可以通過一些手段來迷惑黑客或者別有用心者。

　　1、程序代碼漏洞問題

　　很多 PHP 程序所存在的重大弱點并不是 PHP 語言本身的問題，而是編程者的安全意識不高而導致的。因此，必須時時注意每一段代碼可能存在的問題，去發現非正確數據提交時可能造成的影響。

　　unlink ($evil_var);

　　fwrite ($fp, $evil_var);

　　system ($evil_var);

　　exec ($evil_var);

　　必須時常留意你的代碼，以確保每一個從客戶端提交的變量都經過適當的檢查，然后問自己以下一些問題：

　　此腳本是否只能影響所預期的文件?

　　非正常的數據被提交后能否產生作用?

　　此腳本能用于計劃外的用途嗎?

　　此腳本能否和其它腳本結合起來做壞事?

　　是否所有的事務都被充分記錄了?

　　在寫代碼的時候問自己這些問題，否則以后可能要為了增加安全性而重寫代碼了。注意了這些問題的話，也許還不完全能保證系統的安全，但是至少可以提高安全性。

　　還可以考慮關閉 register_globals， Magic _quotes 或者其它使編程更方便但會使某個變量的合法性，來源和其值被搞亂的設置。

　　2、用戶輸入表單問題

　　驗證用戶輸入的任何數據，保證PHP代碼的安全。

　　注意1：JS只是為了提高來訪用戶的體驗而產生的，而不是驗證的工具。因為任何一個來訪的用戶都可能會，也有可能無意間就禁用了客戶端腳本的執行，從而跳過這層驗證。所以我們必須在PHP的服務器端程序上檢驗這些數據。

　　注意2：不要使用$_SERVER['HTTP_REFERER']這個超級變量來檢查數據的來源地址，一個很小的菜鳥黑客都會利用工具來偽造這個變量的數據，盡可能利用Md5，或者rand等函數來產生一個令牌，驗證來源的時候，驗證這個令牌是否匹配。

　　3、PHP文件權限問題

　　PHP 被設計為以用戶級別來訪問文件系統，所以完全有可能通過編寫一段 PHP 代碼來讀取系統文件如 /etc/passwd，更改網絡連接以及發送大量打印任務等等。因此必須確保 PHP 代碼讀取和寫入的是合適的文件。請看下面的代碼，用戶想要刪除自己主目錄中的一個文件。假設此情形是通過 web 界面來管理文件系統，因此 Apache 用戶有權刪除用戶目錄下的文件。

　　$username = $_POST['user_submitted_name'];

　　$homedir = "/home/$username";

　　$file_to_ = "$userfile";

　　unlink ("$homedir/$userfile");

　　echo "$file_to_ has been d!";

　　既然 username 變量可以通過用戶表單來提交，那就可以提交別人的用戶名和文件名，并刪除該文件。這種情況下，就要考慮其它方式的認證：

　　只給 PHP 的 web 用戶很有限的權限。 -檢查所有提交上來的變量。 -以下是更加安全的文件名和變量的驗證和檢查：

　　$username = $_SERVER['REMOTE_USER'];

　　$homedir = "/home/$username";

　　if (!ereg('^[^./][^/]*$', $userfile))

　　die('bad filename');

　　if (!ereg('^[^./][^/]*$', $username))

　　die('bad username');

　　4、隱藏PHP擴展名

　　一般而言，通過隱藏的手段提高安全性被認為是作用不大的做法。但某些情況下，盡可能的多增加一份安全性都是值得的。

　　一些簡單的方法可以幫助隱藏 PHP，這樣做可以提高攻擊者發現系統弱點的難度。在 php.ini 文件里設置 expose_php = off ，可以減少他們能獲得的有用信息。

　　另一個策略就是讓 web 服務器用 PHP 解析不同擴展名。無論是通過 .htaccess 文件還是 Apache 的配置文件，都可以設置能誤導攻擊者的文件擴展名：

　　# 使PHP看上去像其它的編程語言

　　AddType application/x-httpd-php .asp .py .pl

　　# 使 PHP 看上去像未知的文件類型

　　AddType application/x-httpd-php .bop .foo .133t

　　# 使 PHP 代碼看上去像HTML頁面

　　AddType application/x-httpd-php .htm .html

　　要讓此方法生效，必須把 PHP 文件的擴展名改為以上的擴展名。這樣就通過隱藏來提高了安全性，雖然防御能力很低而且有些缺點。

　　三、Mysql數據庫安全性設置

　　PHP 本身并不能保護數據庫的安全。下面的章節只是講述怎樣用 PHP 腳本對數據庫進行基本的訪問和操作。記住一條簡單的原則：深入防御。保護數據庫的措施越多，攻擊者就越難獲得和使用數據庫內的信息。正確地設計和應用數據庫可以減少被攻擊的擔憂。

　　1、數據庫設計問題

　　應用程序永遠不要使用數據庫所有者或超級用戶帳號來連接數據庫，因為這些帳號可以執行任意的操作，比如說修改數據庫結構(例如刪除一個表)或者清空整個數據庫的內容。以下截圖的用戶設置是危險的。

　　應該為程序的每個方面創建不同的數據庫帳號，并賦予對數據庫對象的極有限的權限。僅分配給能完成其功能所需的權限，避免同一個用戶可以完成另一個用戶的事情。這樣即使攻擊者利用程序漏洞取得了數據庫的訪問權限，也最多只能做到和該程序一樣的影響范圍。

　　2.數據庫連接問題

　　把連接建立在 SSL 加密技術上可以增加客戶端和服務器端通信的安全性，或者 SSH 也可以用于加密客戶端和數據庫之間的連接。如果使用了這些技術的話，攻擊者要監視服務器的通信或者得到數據庫的信息是很困難的。

　　3.數據庫數據的加密

　　SSL/SSH 能保護客戶端和服務器端交換的數據，但 SSL/SSH 并不能保護數據庫中已有的數據。SSL 只是一個加密網絡數據流的協議。

　　如果攻擊者取得了直接訪問數據庫的許可(繞過 web 服務器)，敏感數據就可能暴露或者被濫用，除非數據庫自己保護了這些信息。對數據庫內的數據加密是減少這類風險的有效途徑，但是只有很少的數據庫提供這些加密功能。

　　對于這個問題，有一個簡單的解決辦法，就是創建自己的加密機制，然后把它用在 PHP 程序內，最常見的例子就是把密碼經過 MD5 加密后的散列存進數據庫來代替原來的明文密碼。

　　 0) { echo 'Welcome, $username!'; } else { echo 'Authentication failed for $username.'; } ?>

　　4、SQL注入問題

　　直接 SQL 命令注入就是攻擊者常用的一種創建或修改已有 SQL 語句的技術，從而達到取得隱藏數據，或覆蓋關鍵的值，甚至執行數據庫主機操作系統命令的目的。這是通過應用程序取得用戶輸入并與靜態參數組合成 SQL 查詢來實現的。下面將會給出一些真實的例子。

　　$query = "SELECT id, name, ed, size FROM products

　　WHERE size = '$size'

　　ORDER BY $order LIMIT $limit, $offset;";

　　$result = odbc_exec($conn, $query);

　　可以在原來的查詢的基礎上添加另一個 SELECT 查詢來獲得密碼： select ’1′, concat(uname||’-’||passwd) as name, ’1971-01-01′, ’0′ from usertable; 假如上述語句(使用 ‘ 和 –)被加入到 $query 中的任意一個變量的話，那么就麻煩了。

　　這些攻擊總是建立在發掘安全意識不強的代碼上的。所以，永遠不要信任外界輸入的數據，特別是來自于客戶端的，包括選擇框、表單隱藏域和 cookie。就如上面的第一個例子那樣，就算是正常的查詢也有可能造成災難。

　　永遠不要使用超級用戶或所有者帳號去連接數據庫。要用權限被嚴格限制的帳號。檢查輸入的數據是否具有所期望的數據格式。PHP 有很多可以用于檢查輸入的函數，從簡單的變量函數和字符類型函數(比如 is_numeric()，ctype_digit())到復雜的 Perl 兼容正則表達式函數都可以完成這個工作。

　　如果程序等待輸入一個數字，可以考慮使用 is_numeric() 來檢查，或者直接使用 settype() 來轉換它的類型，也可以用 sprintf() 把它格式化為數字。

　　一個更安全的防止SQL注入的分頁顯示方法：

　　settype($offset, 'integer');

　　$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

　　$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",

　　$offset);

【PHP中的安全性知識】相關文章：

PHP中的Trait11-20

PHP中php://input和$-POST的區別12-01

PHP中list的方法11-17

PHP中Json應用03-01