在現在各種黑客橫行的時候，如何實現自己php**安全，保證程式和伺服器的安全是乙個很重要的問題，我隨便看了下關於php安全的資料，並不是很多，至少比asp少多了，呵呵，於是就想寫點東西，來防止這些可能出現的情況。這裡沒有太深的技術含量，我只是比較簡單的談了談。(以下操作如無具體說明，都是基於php+mysql+apache的情況)
上面文章是安全焦點上的關於php安全的文章，基本上比較全面的介紹了關於php的一些安全問題。
在php編碼的時候，如果考慮到一些比較基本的安全問題，首先一點：
1. 初始化你的變數
為什麼這麼說呢？我們看下面的**：
if ($admin)
echo '登陸成功！';
include('admin.php');
else
echo '你不是管理員，無法進行管理！';
好，我們看上面的**好像是能正常執行，沒有問題，那麼加入我提交乙個非法的引數過去呢，那麼效果會如何呢？比如我們的這個頁是 那麼我們提交：呵呵，你想一些，我們是不是直接就是管理員了，直接進行管理。
當然，可能我們不會犯這麼簡單錯的錯誤，那麼一些很隱秘的錯誤也可能導致這個問題，比如最近暴出來的phpwind 1.3.6論壇有個漏洞，導致能夠直接拿到管理員許可權，就是因為有個$skin變數沒有初始化，導致了後面一系列問題。
那麼我們如何避免上面的問題呢？首先，從php.ini入手，把php.ini裡面的register_global = off，就是不是所有的註冊變數為全域性，那麼就能避免了。但是，我們不是伺服器管理員，只能從**上改進了，那麼我們如何改進上面的**呢？我們改寫如 下：
$admin = 0; // 初始化變數
if ($_post['admin_user'] && $_post['admin_pass'])
// 判斷提交的管理員使用者名稱和密碼是不是對的相應的處理**
$admin = 1;
else
$admin = 0;
if ($admin)
echo '登陸成功！';
include('admin.php');
else
echo '你不是管理員，無法進行管理！';
那麼這時候你再提交 就不好使了，因為我們在一開始就把變數初始化為 $admin = 0 了，那麼你就無法通過這個漏洞獲取管理員許可權。
2. 防止sql injection (sql注射)
sql 注射應該是目前程式危害最大的了，包括最早從asp到php，基本上都是國內這兩年流行的技術，基本原理就是通過對提交變數的不過濾形成注入點然後使惡意使用者能夠提交一些sql查詢語句，導致重要資料被竊取、資料丟失或者損壞，或者被入侵到後台管理。
那麼我們既然了解了基本的注射入侵的方式，那麼我們如何去防範呢？這個就應該我們從**去入手了。
我們知道web上提交資料有兩種方式，一種是get、一種是post，那麼很多常見的sql注射就是從get方式入手的，而且注射的語句裡面一定是包含一些sql語句的，因為沒有sql語句，那麼如何進行，sql語句有四大句：
select 、update、delete、insert，那麼我們如果在我們提交的資料中進行過濾是不是能夠避免這些問題呢？
於是我們使用正則就構建如下函式：
函式名稱：inject_check()
函式作用：檢測提交的值是不是含有sql注射的字元，防止注射，保護伺服器安全
參 數：$sql_str: 提交的變數
返 回 值：返回檢測結果，ture or false
function inject_check($sql_str)
return eregi('select|insert|update|delete|'|/*|*|../|./|union|into|load_file|outfile', $sql_str); // 進行過濾
我們函式裡把 select,insert,update,delete, union, into, load_file, outfile /*, ./ , ../ , ' 等等危險的引數字串全部過濾掉，那麼就能夠控制提交的引數了，程式可以這麼構建：
if (inject_check($_get['id']))
exit('你提交的資料非法，請檢查後重新提交！');
else
$id = $_get['id'];
echo '提交的資料合法，請繼續！';
"提交的資料合法，請繼續！"
如果我們提交 ' select * from tb_name
那麼就達到了我們的要求。
但是，問題還沒有解決，假如我們提交的是 asdfasdfasdf 呢，我們這個是符合上面的規則的，但是呢，它是不符合要求的，於是我們為了可能其他的情況，我們再構建乙個函式來進行檢查：
函式名稱：verify_id()
函式作用：校驗提交的id類值是否合法
參 數：$id: 提交的id值
返 回 值：返回處理後的id
function verify_id($id=null)
if (!$id) // 是否為空判斷
elseif (inject_check($id)) // 注射判斷
elseif (!is_numeric($id)) // 數字判斷
$id = intval($id); // 整型化
return $id;
呵呵，那麼我們就能夠進行校驗了，於是我們上面的程式**就變成了下面的：
if (inject_check($_get['id']))
exit('你提交的資料非法，請檢查後重新提交！');
else
$id = verify_id($_get['id']); // 這裡引用了我們的過濾函式，對$id進行過濾
echo '提交的資料合法，請繼續！';
好，問題到這裡似乎都解決了，但是我們有沒有考慮過post提交的資料，大批量的資料呢？
比如一些字元可能會對資料庫造 成危害，比如 ' _ ', ' % '，這些字元都有特殊意義，那麼我們如果進行控制呢？還有一點，就是當我們的php.ini裡面的magic_quotes_gpc = off 的時候，那麼提交的不符合資料庫規則的資料都是不會自動在前面加' '的，那麼我們要控制這些問題，於是構建如下函式：
函式名稱：str_check()
函式作用：對提交的字串進行過濾
參 數：$var: 要處理的字串
返 回 值：返回過濾後的字串
function str_check( $str )
if (!get_magic_quotes_gpc()) // 判斷magic_quotes_gpc是否開啟
$str = addslashes($str); // 進行過濾
$str = str_replace("_", "\_", $str); // 把 '_'過濾掉
$str = str_replace("%", "\%", $str); // 把' % '過濾掉
return $str;
ok，我們又一次的避免了伺服器被淪陷的危險。
函式名稱：post_check()
參 數：$post: 要提交的內容
返 回 值：$post: 返回過濾後的內容
function post_check($post)
if (!get_magic_quotes_gpc()) // 判斷magic_quotes_gpc是否為開啟
$post = addslashes($post); // 進行magic_quotes_gpc沒有開啟的情況對提交資料的過濾
$post = str_replace("_", "\_", $post); // 把 '_'過濾掉
$post = str_replace("%", "\%", $post); // 把' % '過濾掉
$post = nl2br($post); // 回車轉換
$post= htmlspecialchars($post); // html標記轉換
return $post;
呵呵，基本到這裡，我們把一些情況都說了一遍，其實我覺得自己講的東西還很少，至少我才只講了兩方面，再整個安全中是很少的內容了，考慮下一次講更多，包括php安全配置，apache安全等等，讓我們的安全正的是乙個整體，作到最安全。
最後在告訴你上面表達的：1. 初始化你的變數 2. 一定記得要過濾你的變數
研究顯示移動裝置安全將是未來最大安全挑戰
mcafee共對100位英國業內專家進行了調研，結果發現，當涉及企業安全問題時，各企業最關心的是移動裝置在未來幾個月內大批湧入工作場所。對這一問題的擔憂排名甚至高於確保雲 19 服務中的it與企業聲譽 13 隨著員工希望在工作場合中使用個人裝置的意願不斷增強，自帶裝置 byod 的工作方式已經為全球...
研究顯示移動裝置安全將是未來最大安全挑戰
mcafee共對100位英國業內專家進行了調研，結果發現，當涉及企業安全問題時，各企業最關心的是移動裝置在未來幾個月內大批湧入工作場所。對這一問題的擔憂排名甚至高於確保雲 19 服務中的it與企業聲譽 13 隨著員工希望在工作場合中使用個人裝置的意願不斷增強，自帶裝置 byod 的工作方式已經為全球...
安全 20年最大的技術失敗？
infoworld上評出20年來25個最大的技術失敗。原文可見 其中，排名第一位的是安全？computers influence every aspect of our business lives.we trust them implicitly to manage our records,com...