本文所討論的安全性環境是在linux+apache+mysql+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 的預設設定只能保障一定程度的安全，如果伺服器能夠通過正常的對映規則找到檔案，那麼客戶端便會獲取該檔案，如http://local host/~ 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 語言本身的問題，而是程式設計者的安全意識不高而導致的。因此，必須時時注意每一段**可能存在的問題，去發現非正確資料提交時可能造成的影響。
1 2
3 4 5 6
必須時常留意你的**，以確保每乙個從客戶端提交的變數都經過適當的檢查，然後問自己以下一些問題：
此指令碼是否只能影響所預期的檔案？
非正常的資料被提交後能否產生作用？
此指令碼能用於計畫外的用途嗎？
此指令碼能否和其它指令碼結合起來做壞事？
是否所有的事務都被充分記錄了？
在寫**的時候問自己這些問題，否則以後可能要為了增加安全性而重寫**了。注意了這些問題的話，也許還不完全能保證系統的安全，但是至少可以提高安全性。
還可以考慮關閉 register_globals，magic_quotes 或者其它使程式設計更方便但會使某個變數的合法性，**和其值被搞亂的設定。
2、使用者輸入表單問題
驗證使用者輸入的任何資料，保證php**的安全。
注意1：js只是為了提高來訪使用者的體驗而產生的，而不是驗證的工具。因為任何乙個來訪的使用者都可能會，也有可能無意間就禁用了客戶端指令碼的執行，從而跳過這層驗證。所以我們必須在php的伺服器端程式上檢驗這些資料。
注意2：不要使用$_server[『http_referer』]這個超級變數來檢查資料的**位址，乙個很小的菜鳥黑客都會利用工具來偽造這個變數的資料，盡可能利用md5，或者rand等函式來產生乙個令牌，驗證**的時候，驗證這個令牌是否匹配。
3、php檔案許可權問題
php 被設計為以使用者級別來訪問檔案系統，所以完全有可能通過編寫一段 php **來讀取系統檔案如 /etc/passwd，更改網路連線以及傳送大量列印任務等等。因此必須確保 php **讀取和寫入的是合適的檔案。 請看下面的**，使用者想要刪除自己主目錄中的乙個檔案。假設此情形是通過 web 介面來管理檔案系統，因此 apache 使用者有權刪除使用者目錄下的檔案。
1 2
3 4
5 6
7既然 username 變數可以通過使用者表單來提交，那就可以提交別人的使用者名稱和檔名，並刪除該檔案。這種情況下，就要考慮其它方式的認證：
username!』;
} else ?>4、sql注入問題直接 sql 命令注入就是攻擊者常用的一種建立或修改已有 sql 語句的技術，從而達到取得隱藏資料，或覆蓋關鍵的值，甚至執行資料庫主機作業系統命令的目的。這是通過應用程式取得使用者輸入並與靜態引數組合成 sql 查詢來實現的。下面將會給出一些真實的例子。123456
可以在原來的查詢的基礎上新增另乙個 select 查詢來獲得密碼： union 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注入的分頁顯示方法：
1 2
3 4 5 6
PHP安全性漫談之PHP安全性設定
伺服器並不能阻止所有的安全問題，例如程式漏洞問題 使用者輸入表單問題 php檔案許可權問題等。也可以通過一些手段來迷惑黑客或者別有用心者。1 程式 漏洞問題 很多 php 程式所存在的重大弱點並不是 php 語言本身的問題，而是程式設計者的安全意識不高而導致的。因此，必須時時注意每一段 可能存在的問...
登陸與密碼安全性漫談
多數業務系統都自帶使用者登陸模組，而其中最常見的登陸方式為使用者名稱 密碼，常見的安全性考慮 如下 1 當使用者輸入不存在的使用者名稱時，提示 使用者名稱不存在 更友好？2 當發現某惡意請求後，限ip?某廣告 每日 ip量可達100萬,不重複 3 資料庫儲存明文密碼？所有拿到資料庫訪問許可權的人都知...
mysql安全性試驗 Mysql安全性測試
一 沒有進行預處理的sql語句 1.連線資料庫 conn mysql connect 127.0.0.1 3306 root 518666 if conn die could not connect mysql error 2.選擇資料庫 mysql select db mysql safe con...