php 項目代碼的安全總結

1: 基礎型,
    include $module.'.php'; $module假如直接用GET上得到, 那這是個非常毀滅性的bug, linux下讓你痛不欲生, windows下讓你傾家當產, 這類安全性一般都會被人直接發現, 而有效地阻止. 假如你連這點都沒做到, 請問你是否稱得上合格的程式員?

  2: 質的安全.
    許多人會說, 外部變數應該addslashes一次, 我們先不管addslashes函數是否高效安全, 許多人其實忘記了在使用addslashes之前, 也得注意安全. index.php?aa[]=222&, 這是url, addslashes($aa); 系統會報錯. 由此可見, 我們在使用函數的同時, 理應知道資料類型的不同, 會產生哪種情況. 以前有文章說過, 函數註冊了傳參數>0數字型, 使用者傳入字母,怎麼辦. 許多人認為是函數的錯誤, 在我看來, 是使用者的錯誤, 雖然是自訂函數, 不過你瞞目的傳參數, 不解其中原由, 這點態度上已經很不安全.

  3: 壓力安全.
    目前你偶爾看163的新聞, 會發現, 瀏覽器會突然崩潰, 假死, 甚至瀏覽器"被關閉". 這個原因有可能是網頁程式碼問題, 也有可能是前端js的問題, 特別是js, 由於js特性比較靈活, 在使用迴圈, 賦值方面, 不容易查錯, 比較突出的一點在於取值及錯誤再處理. 比如getelementbyid('mydiv'); 這時, 你是否有想過, mydiv是否存在? 是否被二次修改? 還有一點是圖片, 許多人在圖片<img>無法載入時, 都用onerror去再次顯示預設圖片, 你是否有想過, 假如預設圖片也無法顯示呢? 是不是進入無限迴圈了?

  4: PHP效能安全.
    沒有人能夠說從來沒遇到過無限迴圈導致apache崩潰的, 再優秀的人也都有相同的體會. 迴圈到底都產生了什麼壓力? 影響了哪些效能? 見一段代碼:
    foreach($array AS $val){
     $payarr = include('pay.inc.php');
     if($payarr[0] >= 360 * 1.25 + 568){
  $err[] = $payarr[0];
     }
    }
    這段代碼是可以正常啟動並執行, 不管你include是否成功, 不用判斷是否有意義, 反正它是可以運行成功的. 當然, 它是無意義的. 要真正實現功能需求, 這段代碼得增加好幾行, 全部是判斷. 在引入檔案前, 是否應該先is_file確認檔案是否存在? 既然是在迴圈中, 是否應該使用include_once? 條件值是數字運算, 是否寫個直接值比較好?  在判斷前, 是否應該先判斷$payarr數組值存在與否?

  5: 在寫程式還是寫判斷.
    上面的效能安全講了缺少了許多判斷, 那php是否有文檔顯示, 無謂的判斷是否影響效能. 見代碼.
    if(is_resource($a) === false || is_array($a) === false || is_bool($a) === false)
    echo $a;
    假如我們每次使用變數時都這樣判斷? 是不是更安全? 代碼是沒錯的, echo 僅列印字串類型, 前面的判斷也是符合邏輯思維. 這可能比較像嚴格型安全, 但如果php能夠省略這點效能壓力, 這樣寫也未必不是好事. 至少實現了需求, 也增加了安全性. 當然我們也會在想, 這樣寫的話, 我到底是在寫程式還是在寫判斷?

  6: 屏蔽錯誤.
    許多人在學習php時, 老師關於安全上說過的一句話, 讓他深深記住了, 屏蔽錯誤資訊. 個人認為, 屏蔽錯誤應該是有前提條件的. 即屏蔽顯示出來, 但不能屏蔽記錄. 某天, 一個網頁空白了, 讓程式員查錯誤, 他告訴我, 錯誤被屏蔽了. 你認為這樣合理? 我是讓你屏蔽錯誤, 但沒讓你自己也把自己屏蔽了, 連你自己都不知道錯誤在哪, 普通使用者能知道? 所以, 你在使用php.ini屏蔽, 或者@符時, 切記, 你自己得清楚錯誤發生在哪.

  7: 介面安全.
    相信大家都有做介面安全, 不管你們有木有, 反正我是有的. 通常的做法就是, 請求url,然後php列印值給用戶端, 這樣用戶端就可以做判斷處理, 或者顯示處理. 事實上, 這種做法, 普通的php工作人員很容易通過firebug來得到url,即可知道你得到的參數是什麼, 返回的值是什麼, 這是潛在的危險, 比如商品評論, 商品價格. 為此, 我建議介面做一層token, 先取token然後再傳參數. tokey所做的工作非常有意義, 可以計算使用者是否正常, ip, 請求時間. 在下一步請求介面時, 便可判斷. token值是加密的, 使用者無法使用或者保留, 你也許會問, token就一串字元, 它可以一直保留著請求介面呀. 我滴神. 麻煩把請求時間使用起來呀.

  8: 顯示安全.
    其實我自己也沒完全搞懂顯示安全這問題. 比如需要記錄使用者的簽名吧, 支援html代碼. 那提交後, 入庫mysql前, 資料是addslashes,還是htmlspecialchars呢? 假如是addslashes的話, 那前台顯示時, 就有可能被人xss注入. 假如htmlspecialchars的話, 那前台顯示時, 怎麼把html代碼給顯示出來? 同時又可以防止xss呢?一個網站那麼多變數, 你有一個一個去思考這個問題麼? 怎麼防止攻擊?

  9: 蛋疼的安全.
    不管你們是否相信, 反正我相信sohpex會蛋疼, zend加密後的代碼似乎在php5.3版本後無法使用. 你這安全做得太不靠譜了, 原來是公關安全, 竟然移交給程式員去實現. 商業模式不帶這樣玩的