資安新聞筆記-開發網站前該知道的二三事
最近有兩則資安新聞引發我的注意:
資安這檔事是這樣的，平時只會覺得系統被設了一堆限制綁手綁腳，稽核單位訂下的規矩不勝其擾，防毒軟體防火牆是效能毒藥，這一切代價換來多少功效? 卻無人知曉，直到某天豬隊友忽然來報到，才後悔資安防範做得還是太少。
有鑑於對於資安重要性的體驗常來自"多麼痛的領悟"，多遇個幾次，還來不及大徹大悟前，往往命就先去了半條。(甚至歷史上也曾有因資安事件而死的悲慘案例: 因公司產品內含SQL Injection漏洞導致10萬個網站被摧毁，軟體公司LxLabs的老板承受不了壓力，選擇在家中懸樑自盡)
因此，由別人的血淚經驗記取教訓看起來是比較人性化的學習成長途徑，每每看到資安新聞，我都會默默整理分析，找出在這些個案中開發者犯了什麼錯? 尤其是"不管哪種語言、何種平台，一旦誤觸結局都一樣慘"的觀念性錯誤!
或許我們的資安工作未必做得比事件苦主好，但從案例中推敲別人可能犯下的疏失，絕對可以當成借鏡，從中吸取教訓藉以自省，而以這兩次事件為例:
- 後台與前台的存取管道應加以區隔
在戰場上曝露的面積愈大，中槍風險愈高! 而Internet，就是駭客及惡意者四伏的戰場。金流平台的後台查詢報表完整出現在Google可搜尋範圍，講起來也算一種裸奔行為。
若後台永遠只會由辦公室內存取，就沒有必要架構在Internet可以存取的網段。若後台需開放特定但固定的廠商、客戶存取，則採事先登記，限定來源IP也是能有效縮少曝露面的方法。而最重要的是，無論如何都不應開放匿名存取! - 權限管控應落實於頁面層次，甚至功能層次
此點純屬猜測，因金流明細報表原本就設定可匿名存取的機率不高，推測最後曝露的原因來自權限管控設計不良。舉個例子來說，曾看過某個兩光的權限設計只做在選單層次，有權限的人才看得到選項，從URL導向特定網頁。設計者天真地以為: 會到這個網頁來的，一定是選單有出現選項，知道URL才會過來，所以網頁本身未再次檢查權限。假設，若某使用者權限被拔除，但仍可在瀏覽歷史記錄中找到該網址呢? 如果某個有權限使用者把URL記在Word裡，寄給別人參考或檔案被人偷走呢?
選單固然應依使用者權限決定是否顯示選項連結，但在頁面中應該再次檢查使用者身分與權限才是王道，甚至若頁面中各功能權限有別時，別只是把不能用的鈕隱藏起來就算了，應在執行該功能前再做一次檢查。 - 不要用明碼或加密形式儲存密碼，雜湊才是王道
CSDN密碼外洩的最大敗筆在於密碼是明碼!
如果你有幸被賦與設計密碼相關資料表Schema的重責大任，請切記! 若你設計用明碼方式儲存密碼，你是大豬頭；若你決定用加密方式儲存密碼，你還是豬頭!
較佳的做法是只保存密碼的雜湊值，而不保存密碼本身(明碼或加密後都算)，未來可供比對使用者輸入的密碼是否吻合，卻無法用以反推密碼為何。
如此，使用者不用擔心密碼外洩被第三者知道，系統也不必承擔密碼內容有可能外流的風險。
儲存加密後的密碼雖具初步防護力，一旦加密演算法及金鑰一併失守，照樣一次輸個精光。
那麼，系統不知道使用者密碼，使用者忘記密碼時怎麼辦? 重寄密碼給使用者做為提醒? 請不要再當豬頭了。忘記密碼時，請重設一組隨機密碼寄給使用者，允許其在一段時間內使用它登入系統重設新密碼，要把握"系統永遠不知道使用者的密碼為何，只有權重新指定 "的重要原則。 - 不要輕忽備份保存的安全性
有些線上系統戎備森嚴，受防火牆層層包圍，想存取需通過層層查驗。當線上資料備分出來後，縱然與線上資料價值相去不遠，但一被封裝在外表平凡的磁帶匣或肥大乏味的ZIP/BAK檔裡，就很容易讓人忽略其重要性與保密需求，於是存取管控嚴謹性一落千丈，甚至為了挪出空間，就隨著一群檔案被移置到某個公共空間，搞不好還被不知情第三者燒成光碟以清出HD空間，又在某天被丟進回收箱...
建議所有寫網站的朋友，不管你用的是什麼語言工具，什麼伺服器平台，都要勤於吸收資安相關知識，對於資安新聞(要用心找，像金流平台裸奔的消息就在一片前縣長夫人看丁字褲的新聞中被無視了)要保持敏銳度，很多的資安惡習或錯誤觀念，都是不受程式、平台疆界限制的，由別人的過失中吸收經驗，才能減少犯錯，降低當上豬隊友的機會!
最後，不能免俗地還是要政策宣導一下，雖然未在本次事件中露臉，但如果你還不認識足以奪走人命的資安事件一哥--SQL Injection，或者能用Parameter寫SQL指令時還是堅持一定自己組字串，請立即雙手打上石膏裝殘，先不要寫任何程式以免禍害千年，感謝您的配合~~
【延伸閱讀】