Web Security Notes

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 21 – ANTI-CACHING HEADERS 作者：John Melton What is it and why should I care? It's under the mat, I knew it. 快取( Caching )是一種技巧，將伺服器上遠地的資料儲存一份副本在本地端，減少重複下載的動作，增加使用效能。只考慮效能的話，快取真是太棒。從資安的角度來看，可能成為很嚴重的問題。 假設現在螢幕上顯示你的個人銀行帳戶或醫療紀錄，下個使用者甚至不需要登入就可以看到剛剛的資料。 幸運的是，我們可以藉由指令啟用或關閉快取。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 20 – TRUST NOTHING 作者：John Melton Don't worry ^_^ What is it and why should I care? 信任感是很有趣的議題，我們潛意識中相信人性本善，開發者也是。看看以下這個例子： //bad bad do not use executeDbQuery("select * from my_table where id = " + request.getParameter("my_id")); //bad bad do not use 開發者相信使用者不會竄改 my_id 所以放心的直接帶入 executeDbQuery()。這太天真了，正確作法應該是用 my_id 參數傳入到 Prepare Statement 以防止 SQL Injection 同時檢查 my_id 的內容是否正確。 為何要如此大費周章？因為我們不能隨便相信輸入值，不能相信使用者會依照我們的期望使用系統。我們必須建造好用的、能承受攻擊的、強壯且吃苦耐勞的系統。無論你的系統是甚麼類型，作者建議不要信任( Trust )系統會接觸到的環境。 「不能信任系統環境」到底代表什麼意涵？是為了避免 XSS 和 SQL injection 嗎？是，但更深一層的意涵是以不同的方式了解應用程式。應用程式其實是規模不同的輸入-處理-輸出的過程，輸入值可能是 request parameters、headers、database input 等等，處理包括身分驗證、邏輯，輸出到資料庫、螢幕、檔案等等。整個應用程式可以當成所有系統元件的輸入值、處理、輸出的結合，並縮放規模到適合的系統和組織。 所謂的「環境」因人而異，「你不能相信任何人」也是因地制宜。作者的建議是我們應分辨可以相信的和不能相信的，不能相信的資料應視之為已經被汙染的資料。 威脅模擬( Threat Modeling )中包含許多此類議題，日後的文章作者會介紹。

來源：John Melton's Weblog 標題： YEAR OF SECURITY FOR JAVA – WEEK 19 – REDUCE THE ATTACK SURFACE 作者：John Melton Police: Suspect is not going to get through. What is it and why should I care ? 減少應用程式的攻擊進入點(  attack surface   )代表減少與應用程式互動的方式，且可能減少應用程式的功能性。 對於一秒幾十萬上下的老闆們可真是個壞消息。然而我們只是要回歸系統的初衷─簡單化。其實簡單化對於企業是件好事。你很少看到有人因為某個產品超難用，反而感到心情愉悅。最方便的設計就是簡單好用，最安全的設計也是。 那該如何簡化？作者最愛的例子是 Google  標準搜尋框  和  進階搜尋頁面 ，大約99.99%的人不會用的進階搜尋功能被設計在安分的角落。假設Google移除進階功能，可以相對的簡化"搜尋"功能，可以簡化應用程式的腳印、節省記憶體、達到更好的顧客經驗。 許多開發人員都想做些很酷很炫的功能，結果程式碼發展的比計畫中還要肥大，也干擾使用者的心情。請無情地移除不必要的功能、優雅的簡化，就能改善使用者經驗和提升安全性，還可以省錢和省時間。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 18 – PERFORM APPLICATION LAYER INTRUSION DETECTION 作者：John Melton I'm watching you...( ´థ_థ）σ What is it and why should I care? 作者認為應用程式的保護機制中，  應用層的入侵偵測機制  是非常有效的。目前為止的主題都是關於軟體生命週期的開發階段，但這篇文章卻橫越整個應用程式範圍，從需求到規劃，最終上線階段。 基本概念是擬定計畫、實作並監控"不好的事件"。這種系統的特性是尋找意料外的事件並持續追蹤。經過一段時間後，再判斷是否應將那些事件列為攻擊事件。 很多開發者都已經下了功夫去偵測事件，看看以下的範例pseudo-code： if (使用者有權存取資料) {     get 資料     redirect 檢視(或編輯)的頁面 } else {     log 例外狀況     send 錯誤訊息給使用者 } 作者看過太多上述的例子。其中有個問題是管理例外狀況。通常，人們寧願盯著螢幕發呆或打掃環境也不願意檢查 logs，所以當攻擊者進攻你的應用程式，唯一看到錯誤訊息的只有他。只要增加通知功能、送出訊息到入侵偵測引擎，你就可以追蹤事件並了解應用程式的實際使用狀況。偵測到入侵事件後，你就能夠把入侵者吊起來打...我的意思是以合法的方式回應入侵行為。一般來說，你可以增加紀錄的頻率、操作使用者帳戶、或禁止存取某些功能。