發表文章

目前顯示的是 五月, 2012的文章

資安JAVA(二一): Anti-Caching Header

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

幸運的是,我們可以藉由指令啟用或關閉快取。

資安JAVA(二十): 不要相信其他人(Trust Nothing)

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 20 – TRUST NOTHING
作者:John Melton
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 )中包含許多此類議題,日後的文章作者會介紹。

資安JAVA(十九): 減少攻擊進入點

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 19 – REDUCE THE ATTACK SURFACE
作者:John Melton
What is it and why should I care ?


減少應用程式的攻擊進入點( attack surface)代表減少與應用程式互動的方式,且可能減少應用程式的功能性。
對於一秒幾十萬上下的老闆們可真是個壞消息。然而我們只是要回歸系統的初衷─簡單化。其實簡單化對於企業是件好事。你很少看到有人因為某個產品超難用,反而感到心情愉悅。最方便的設計就是簡單好用,最安全的設計也是。

那該如何簡化?作者最愛的例子是 Google 標準搜尋框 和 進階搜尋頁面,大約99.99%的人不會用的進階搜尋功能被設計在安分的角落。假設Google移除進階功能,可以相對的簡化"搜尋"功能,可以簡化應用程式的腳印、節省記憶體、達到更好的顧客經驗。

許多開發人員都想做些很酷很炫的功能,結果程式碼發展的比計畫中還要肥大,也干擾使用者的心情。請無情地移除不必要的功能、優雅的簡化,就能改善使用者經驗和提升安全性,還可以省錢和省時間。

資安JAVA(十八): 偵測應用層的入侵

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 18 – PERFORM APPLICATION LAYER INTRUSION DETECTION
作者:John Melton
What is it and why should I care?

作者認為應用程式的保護機制中, 應用層的入侵偵測機制 是非常有效的。目前為止的主題都是關於軟體生命週期的開發階段,但這篇文章卻橫越整個應用程式範圍,從需求到規劃,最終上線階段。

基本概念是擬定計畫、實作並監控"不好的事件"。這種系統的特性是尋找意料外的事件並持續追蹤。經過一段時間後,再判斷是否應將那些事件列為攻擊事件。

很多開發者都已經下了功夫去偵測事件,看看以下的範例pseudo-code:

if (使用者有權存取資料) {
    get 資料
    redirect 檢視(或編輯)的頁面
} else {
    log 例外狀況
    send 錯誤訊息給使用者
}


作者看過太多上述的例子。其中有個問題是管理例外狀況。通常,人們寧願盯著螢幕發呆或打掃環境也不願意檢查 logs,所以當攻擊者進攻你的應用程式,唯一看到錯誤訊息的只有他。只要增加通知功能、送出訊息到入侵偵測引擎,你就可以追蹤事件並了解應用程式的實際使用狀況。偵測到入侵事件後,你就能夠把入侵者吊起來打...我的意思是以合法的方式回應入侵行為。一般來說,你可以增加紀錄的頻率、操作使用者帳戶、或禁止存取某些功能。