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 執行特別敏感的操作之前，須要再次進行身分鑑別。    V2.10 使用者的憑證應定期失效。    V2.11 為了維持身分鑑別的真確性，身分鑑別控制措施應集中化建置，跟鑑別有關的功能都應使用相同的控制措施。    V2.12 所有身分鑑別的結果都應記錄( Logging )。    V2.13 所有密碼都應加入獨

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架構範例