伺服器並不能阻止所有的安全問題，例如程式漏洞問題、使用者輸入表單問題、php檔案許可權問題等。也可以通過一些手段來迷惑黑客或者別有用心者。
1、程式**漏洞問題
很多 php 程式所存在的重大弱點並不是 php 語言本身的問題，而是程式設計者的安全意識不高而導致的。因此，必須時時注意每一段**可能存在的問題，去發現非正確資料提交時可能造成的影響。
必須時常留意你的**，以確保每乙個從客戶端提交的變數都經過適當的檢查，然後問自己以下一些問題：
此指令碼是否只能影響所預期的檔案？ 非正常的資料被提交後能否產生作用？ 此指令碼能用於計畫外的用途嗎？ 此指令碼能否和其它指令碼結合起來做壞事？ 是否所有的事務都被充分記錄了？
在寫**的時候問自己這些問題，否則以後可能要為了增加安全性而重寫**了。注意了這些問題的話，也許還不完全能保證系統的安全，但是至少可以提高安全性。
還可以考慮關閉 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 變數可以通過使用者表單來提交，那就可以提交別人的使用者名稱和檔名，並刪除該檔案。這種情況下，就要考慮其它方式的認證：
只給 php 的 web 使用者很有限的許可權。 檢查所有提交上來的變數。
以下是更加安全的檔名和變數的驗證和檢查：
4、隱藏php副檔名
一般而言，通過隱藏的手段提高安全性被認為是作用不大的做法。但某些情況下，盡可能的多增加乙份安全性都是值得的。
一些簡單的方法可以幫助隱藏 php，這樣做可以提高攻擊者發現系統弱點的難度。在php.ini檔案裡設定 expose_php = off ，可以減少他們能獲得的有用資訊。
另乙個策略就是讓 web 伺服器用 php 解析不同副檔名。無論是通過.htaccess檔案還是 apache 的配置檔案，都可以設定能誤導攻擊者的副檔名：
# 使php看上去像其它的程式語言
# 使 php 看上去像未知的檔案型別
# 使 php **看上去像 html 頁面
要讓此方法生效，必須把 php 檔案的副檔名改為以上的副檔名。這樣就通過隱藏來提高了安全性，雖然防禦能力很低而且有些缺點。
PHP 安全性漫談
本文所討論的安全性環境是在linux apache mysql php。超出此範圍的安全性問題不在本文範疇之內 一 apache server安全性設定 1 以nobody使用者執行 一般情況下，apache是由root 來安裝和執行的。如果apache server程序具有root使用者特權，那麼...
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...
安全性測試
1.url哪些引數可以放進去，哪些不可以放。後面的id 可以隨便改，可以查所有活動。url作處理 後端限制。編輯 時，不應帶有 id，防有人改id編輯其它人的 加密。比如每個使用者金鑰都不一樣，很難破解。2.有些操作自已去資料庫確認，而不靠control層。比如，編輯活動時活動時，活動還沒有開始，但...