程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> 關於PHP編程 >> php 項目代碼的安全總結

php 項目代碼的安全總結

編輯:關於PHP編程

在用php開發項目時很多時間我們模塊化的開發,這時就可以可能存在很多安全隱藏了,下面是我總結的一些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版本後無法使用. 你這安全做得太不靠譜了, 原來是公關安全, 竟然移交給程序員去實現. 商業模式不帶這樣玩的

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved