Web Security Notes

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 17 – SET A HARD SESSION TIMEOUT 作者：John Melton 內文： Bank website: Warning ! Push F5 before expired. What is it and why should I care? 對於應用程式來說，Session 逾時機制是很重要的安全控制措施。這機制主要是在使用者登入一段時間後，強制使用者重新進行身分鑑別。逾時機制分為兩種：軟性和硬性。 硬性 Session 機制限制使用者登入一段時間後，必定要重新登入。以下是個範例，假設我們有個應用程式是： 需要經過身分鑑別才能使用應用程式 嘗試瀏覽應用程式時會轉向到登入頁面 使用者登入後，無論動作中或停止，只要超過 9 小時就必須登出，因此你的硬性 Session 逾時機制上限為 9 小時。 最終效果是，當使用者回到桌面重新點選應用程式後，將會被轉向到登入頁面。 上一段主要是講解硬性機制如何使用，但是硬性機制能避免甚麼弱點？雖然軟性機制能避免 CSRF 和類似的攻擊，硬性逾時機制則是避免攻擊者能永久持有受害者的帳戶，因為他們勢必要重新鑑別身分。為了避免這樣的事情發生，當使用者修改密碼時也應該要重新鑑別身分。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 16 – SET A SOFT SESSION TIMEOUT 作者：John Melton 內文： What is it and why should I care? 對於任何應用程式 ，Session 的定期逾時都是重要的安全控制機制。此機制定義一段時間內使用者都能以登入的身分使用應用程式，直到時間截止則需要重新進行身分鑑別(再次登入)。逾時機制分為兩種：軟性逾時和硬性逾時。今日作者將為你介紹軟性逾時。下周會介紹硬性逾時。 軟性逾時應用在，當使用者停止互動、閒置超過一段時間。 以下舉例，假設我們的應用程式是： 需要經過身分鑑別才能使用應用程式 嘗試瀏覽應用程式時會轉向到登入頁面 使用者登入後，突然有事離開20分鐘，而你只有15分鐘的逾時 綜合以上，當使用者回到桌面重新點選應用程式後，將會被轉向到登入頁面。 這樣的情境表達了軟性逾時如何運作，但究竟這樣的機制是在保護什麼？有關的問題很多，包括身分鑑別、授權、稽核、Session Hijacking，但最主要還是針對 CSRF 。一段合理的時間後的自動登出相當程度的降低 CSRF 類別的攻擊。更精確的說，任何想要利用使用者已登入的合法性進行攻擊，利用這樣簡單的機制都能有效的阻止，至少能提高複雜度。

Level 3 & 4 詳細的的驗證要求有哪些? ASVS 驗證要求細項共分為14大項。 V1. 建立安全架構的文件(Security Architecture) 為了滿足基礎安全，你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能對應到高階安全架構。Level 3 應滿足 ，Level 4 應滿足 ：    V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。    V1.2 能正確辨識不屬於應用程式內但被引用的元件。    V1.3 針對應用程式的高階架構建立文件。例如:  MVC 、 UML 、 企業流程 等。    V1.4 不屬於應用程式內但被引用的元件，應對應到企業功能或安全功能。    V1.5 提供威脅模擬資訊( Threat Modeling )。 V2. 身分鑑別(Authentication) 本項目將要求你安全的建立和控管使用者的認證資訊。Level 3 應滿足 ，Level 4 應滿足 ：    V2.1 除了公開資源以外，所有頁面和資源都須經過身分鑑別，才能存取。    V2.2 所有密碼不能以任何方式顯示在網頁上。    V2.3 當身分鑑別的失敗次數過多，應用程式需自動將該帳號鎖定，而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。    V2.4 所有的身分鑑別控制措施都實作在 Server 端。    V2.5 身分鑑別的控制措施即使失效，也應安全的失效(  Fail Securely  )。    V2.6 身分鑑別的使用者憑證( Credential、Password )應具有一定強度，能抵抗開發環境的一般攻擊。    V2.7 使用者帳戶的管理功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。    V2.8 使用者修改憑證的功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。    V2.9 執行特別敏感的操作之前...

ASVS Level 4 內部流程驗證(Internal Verification) 本階段適合用於保護生命安全、重要基礎設施、國防功能、處理敏感資產的應用程式。面對的威脅主要來自病毒、蠕蟲、使用工具或開發特殊工具的惡意攻擊者。檢驗範圍除了應用程式本身、第三方API的能否提供相同的安全功能、還有使用於應用程式中全部的程式碼。Level 4 要求安全控制措施必須正常運作、佈署在應用程式中且滿足特殊政策( Policies )規範、遵守安全程式碼撰寫實例。Level 4不再分為兩個子項目。 ASVS Level 4 MVC高階架構圖 & 攻擊者路徑圖

ASVS Level 3 系統設計驗證(Design Verification) 本階段適合用於重要的企業交易、健康照護資訊、企業核心功能的應用程式。面對的威脅主要來自病毒、蠕蟲、使用工具或開發特殊工具的惡意攻擊者。檢驗範圍除了應用程式本身，也包括第三方API的能否提供相同的安全功能。Level 3注重安全控制措施正常運作、而且佈署在應用程式中滿足應用程式的政策( Policies )。Level 3不再分為兩個子項目。 ASVS Level 3 MVC高階架構圖 & 攻擊者路徑圖

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 15 – AUDIT SECURITY RELATED EVENTS 作者：John Melton 內文： Always keep an eye on the system. What is it and why should I care? 稽核安全性和兩個原則有關，我們將分開介紹。 稽核Auditing 任何軟體系統最重要的一部份就是稽核。儘管紀錄( Logging )和稽核( Auditing )的涵義並不相同，仍有許多人以為是同一件事。兩者詳細定義因地制宜，我的定義則是看處理Output的接收者而定。一般情況，Logs的接收者通常是：為了除錯的開發者、或是為了觀察某些趨勢的企業主。稽核的用途則是讓稽核員重建曾發生在系統上的事件，檢視事件時通常被限制只能觀察到某段時間的內容，而且只有特殊使用者才擁有這種功能。 通常，Logs資料很雜亂、其內容可能指向任何事情。稽核紀錄則是整理過的資料，能以類似資料庫的方式、依據不同欄位檢視資料。 資安事件Security Related Events 你可以根據需要定義資安事件，但有些是公認的資安事件，譬如登入、登出、使用者管理、憑證( Credential )管理。這些都是跟你的使用者有關係的重要資安事件。 知道資安事件已經發生了，是非常重要的。如果沒有，不僅系統會被未授權存取而且你根本不曉得已經發生了。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 14 – STORE JSPS IN WEB-INF 作者：John Melton 內文： Administrator: STOP!! No further step! What is it and why should I care? Java Server Pages (JSPs)是J2EE的開發環境中上最普遍的UI技術。使用者透過JSP頁面與應用程式互動。JSP也包含著一些商業邏輯，通常某部分的JSP頁面要先經過授權才能使用。而且將使用者跳轉( Forward )到特定JSP頁面前，作為保護作用，處理要求的程式會先執行身分驗證。最起碼，JSP頁面通常含有重要的邏輯和資料，所以基本上JSP不能被未經授權的使用者存取。 當你更了解這項資源的重要性，更應該要保護他們。一般來說，現今的應用程式通常使用MVC架構。進一步的說，正常的使用應用程式並不能直接存取到JSP，而是MVC架構中的Controller或Handler依據你的要求和處理邏輯，將你跳轉到特定JSP。然而，如果你將JSP存放在WEB環境中可讀取的目錄，而不是放在 WEB-INF (web.xml 所在的目錄)，其他人還是可以直接存取你的JSP。他們缺少Controller傳來的指示，或未經過適當的授權，導致你的JSP頁面出現錯誤畫面。 附註：同樣的問題可以延伸到config檔、scripts檔等等，但JSP被公認是WEB應用程式中，一般使用者最常存取的資源型態。而且config檔預設就存放在WEB-INF目錄中，簡化了開發者的工作。

什麼是 Level 2A 安全測試(Penetration Test)? 本階段的要求細項又稱為人工滲透測試要求。你必須建立動態測試以驗證應用程式符合適當的設計、適當的實作和適當的使用安全控制措施。以下是 2A 的安全架構要求： L2A.1 根據 Level 2A 的驗證要求細項(Detail Verification Requirements)，人工執行應用程式的安全測試。 什麼是 Level 2B 原始碼檢查(Code Review)? Code Review 指的是對應用程式的原始碼以人工搜尋和分析，來驗證應用程式符合適當的設計、適當的實作和適當的使用安全控制措施。以下是 2B 的安全架構要求： L2B.1 根據 Level 2B 的驗證要求細項(Detail Verification Requirements)，人工執行應用程式的原始碼檢查。 驗證者可以抽樣檢查，確立安全控制措施的正確使用方式。並整理一份弱點特徵的文件作為軟體基本規則，使開發者可以有信心找出並修復應用程式的問題。而檢測的原則是要盡量收斂，也就是說，來自同樣來源的不同弱點應該視為同一弱點。

ASVS Level 2 人工驗證(Manual Verification) Level 2 適合牽扯到個人金流、企業交易、信用卡資訊、個人身分資料的應用程式。除了使用正確的  安全控制措施(Security Control)  同時控制措施也能有效的運作。面對的威脅主要來自病毒、蠕蟲、使用現成工具的攻擊者。檢驗範圍除了應用程式本身，也包括第三方API的能否提供相同的安全功能。 Level 2 又分為 2A 和 2B ，兩者都能涵蓋 Level 2 的要求項目，差別在於檢測的方法不同。2A 著重人工滲透測試(  Penetration Test  )，2B則著重在人工原始碼檢查( Code Review )。雖然 Level 1 是 Level 2 的子集合，同樣的要求雖然在 Level 1已經通過自動化工具的檢測，但 Level 2 要以人工滲透測試或原始碼檢查才算通過。因為自動化工具只能檢測出應用程式的漏洞，又稱為負向驗證。工具無法提供足夠的證明這些要求細項是否通過正向驗證。 人工檢測不代表不能使用自動化工具。即使這些工具或許有能力找出應用程式的漏洞，但只能用來幫助分析員找出和評估哪些安全控制措施該接受檢測。 ASVS Level 2 MVC架構範例