應用安全性測試指導規范（草稿）1. 進行應用安全性測試的場景安全性測試的目的是驗證集成在軟件內的保護機制是否能夠在實際環境中保護系統的安全性。從嚴格意義上，應用系統的安全性將涉及到應用的設計、開發和部署這三個主要環節，因而理想化的應用安全性測試應是與整個軟件開發過程緊密集成的，即在軟件設計、開發、測試和部署的過程中動態檢測程序代碼的安全性，并在應用最終部署之后進行全面的安全性測評。只有將應用和代碼安全的管理融入到應用開發、部署、運維的各環節中，才能確保應用系統的安全性。在應用系統上線并進入運維階段之后，也需要在維護性開發過程中進行類似的代碼安全性測試，并在日常的應用維護過程中動態進行應用整體安全性的評測。代碼安全性作為應用安全性中的一個核心的內容，是保障代碼開發安全性的一個重要的舉措，在開發活動結束的節點上應重點加強。而應用開發完畢后的部署和運維環節中，還將涉及到應用系統整體安全性評估的其他內容（包括網絡安全、操作安全、權限安全、數據安全等）。應用安全性測試的相關文檔應納入項目管理和運維管理的文檔管理體系。1.1 初期的應用安全性測試場景在傳統的軟件開發管理模式中引入應用安全測試將需要一個逐步的過程，在初期建議在如下的應用場景下，對目標應用系統的安全性進行測試：應用開發階段 新應用軟件開發完畢，通過開發團隊內部測試，即將交付驗收測試之前，應組織對應用代碼進行安全性測試。 新應用軟件部署完畢之后，應組織對目標應用系統進行整體的安全性測評。應用維護階段 應用軟件在維護性開發完畢，通過維護團隊內部測試，即將交付驗收測試之前，應組織對維護開發所涉及部分的代碼安全性進行測試。 應用軟件維護性開發部分部署或系統軟硬件架構重大變更實施完畢之后，應組織對目標應用系統受影響部分進行安全性補充測評。1.2 目標的應用安全性測試相關場景而從更完整意義上的應用系統整個生命周期各階段中，需要進行的應用系統安全性測試、評估的工作可大致規劃如下（供參考）：應用設計階段 應用項目立項時，應明確系統的安全目標和安全功能需求，并通過用戶方的（建設方案）評審。 應用軟件設計方案中應增加系統安全性設計部分，細化目標系統的安全目標和安全功能，并通過用戶方組織的（實施方案）評審。 應用軟件測試方案中應增加系統安全性測試內容，提供細化的安全性測試方案，并通過用戶方組織的（測試方案）評審。應用開發階段 在應用代碼開發的自測和集成測試階段，利用IDE整合的代碼分析工具，對開發的代碼安全性進行動態評估。（項目團隊自評） 新應用軟件開發完畢，通過開發團隊內部測試，即將交付驗收測試之前，應組織對應用代碼進行安全性測試。（第三方代碼安全測評）應用上線階段 新應用軟件部署完畢之后，應組織對目標應用系統進行整體的安全性測評（根據安全測試方案）及整改。（第三方應用安全整體測評）應用維護階段 應用軟件在維護性開發完畢，通過維護團隊內部測試，即將交付驗收測試之前，應組織對維護開發所涉及部分的代碼安全性進行測試。 應用軟件維護性開發部分部署或系統軟硬件架構重大變更實施完畢之后，應組織對目標應用系統受影響部分進行安全性補充測評。 應用日常維護過程中，應根據應用安全等級，定期進行應用安全性評測和改進。（例行應用安全測評）2. 應用安全性測試的范圍與內容應用安全性測試的范圍與內容，應包括如下幾個方面：測評項測評內容部署與基礎結構 網絡是否提供了安全的通信 部署拓撲結構是否包括內部的防火墻 部署拓撲結構中是否包括遠程應用程序服務器 基礎結構安全性需求的限制是什么 目標環境支持怎樣的信任級別輸入/輸出和編碼 如何驗證輸入 是否清楚入口點 是否清楚信任邊界 是否驗證Web頁輸入 是否對傳遞到組件或Web服務的參數進行驗證 是否驗證從數據庫中檢索的數據 是否將方法集中起來 是否依賴客戶端的驗證 應用程序是否易受SQL注入攻擊 應用程序是否易受XSS攻擊 應用程序是否易受OS注入攻擊 應用程序是否易受Cookie定制/隱藏文件操縱攻擊 如何處理輸入 輸出信息是否涉及泄密 數據編碼處理過程是否存在安全漏洞身份驗證 是否區分公共訪問和受限訪問 是否明確服務帳戶要求 如何驗證調用者身份 如何驗證數據庫的身份 是否強制試用帳戶管理措施訪問授權 如何向最終用戶授權 如何在數據庫中授權應用程序 如何將訪問限定于系統級資源配置管理 是否支持遠程管理 是否保證配置存儲的安全 是否隔離管理員特權敏感數據 是否存儲機密信息 如何存儲敏感數據 是否在網絡中傳遞敏感數據 是否記錄敏感數據會話管理 如何交換會話標識符 是否限制會話生存期 如何確保會話存儲狀態的安全加密 為何使用特定的算法 如何確保加密密鑰的安全性參數操作 是否驗證所有的輸入參數 是否在參數過程中傳遞敏感數據 是否為了安全問題而使用HTTP頭數據異常管理 是否使用結構化的異常處理 是否向客戶端公開了太多的信息審核和日志記錄 是否明確了要審核的活動 是否考慮如何流動原始調用這身份源代碼錯誤 緩沖區溢出漏洞。 字符串格式化漏洞。 優先權提升漏洞。3. 應用安全性驗收的流程與方法3.1 應用安全性驗收的流程應用安全性驗收的流程圖如下：3.1.1 IT項目安全測評保護要求管理（1）上海電信內部IT系統的分級安全保護要求的編制與復審規劃處牽頭，會同各應用域及信息中心、移動業務支撐中心共同編制上海電信內部IT系統的分級安全保護要求。規劃處負責定期組織對編制的IT系統分級保護要求進行評估和復審，確保該要求能反映業務需求的變化，并適應于當前的內部IT基礎架構現狀。（2）上海電信內部IT系統安全保護評估指南的編制與復審規劃處負責牽頭并會同相關的安全測評服務商，根據IT系統分級保護要求細化并制定上海電信內部IT系統安全保護評估指南，作為各IT項目驗收環節系統安全保護能力測評與驗收的參考基準。規劃處在IT系統分級保護要求變更后，應及時組織對IT系統安全保護評估指南文檔做相應調整與更新。3.1.2 IT項目安全測評管理（1）安全測評方案編制與評審在IT項目的實施方案編制階段，由電信項目經理牽頭，組織相關應用域、IT項目承建方、第三方安全測評服務商依據上海電信內部IT系統安全保護評估指南共同編制該IT項目的安全測評方案。項目安全測評方案編制完成后，應和項目實施方案一同進行實施方案的評審環節。（2）IT項目安全測評IT項目承建方在完成項目建設實施工作后，在正式提出項目驗收請求之前，向第三方安全測評服務商申請進行項目安全測評。第三方安全測評服務商將按照評審通過的項目安全測評方案，組織現場安全測評，匯總測評結果并提出安全整改意見給IT項目承建方和電信項目經理。IT項目承建方在接到項目安全整改意見后，應及時組織針對性的安全整改工作，并向第三方測評服務商申請整改復審。第三方測評服務商在收到整改復審申請后，針對整改意見進行復審測評，直至所有整改項均符合要求。全部測評項通過后，第三方測評服務機構出具項目安全測評報告，并匯總測評相關技術文檔提交至電信項目經理。電信項目經理在收到項目安全測評報告后，組織常規的IT項目驗收工作，并在項目驗收時將安全測評相關文檔并入項目技術文檔保存。（3）IT項目的移交在IT項目建設完畢后的維護移交階段，應同步將應用系統的安全要求和安全保護指南轉換為相應的應用系統安全維護指南，作為應用維護階段的安全維護基準。3.1.3 IT項目運維安全測評管理（1）維護性開發的安全測評在維護性開發工作啟動階段應參照應用系統安全維護指南確定維護性開發相關部分的安全保護評估指南，并細化為對應的安全測試方案，作為維護性開發結束的安全評估的基準。維護性開發工作結束，由移動業務支撐中心牽頭，組織相關應用域、維護服務提供商、第三方安全測評服務商共同完成維護性開發涉及部分系統的安全測評和整改，并作為維護性開發驗收的必要條件之一。（2）日常維護安全測評移動業務支撐中心應根據應用系統安全維護指南，組織第三方安全測評服務商按照應用系統的分級安全保護要求進行定期的系統安全測評，并根據測評結果對IT基礎架構、應用系統進行必要的安全改進。應用系統的日常安全維護文檔也納入維護文檔管理體系。3.2 應用安全性測試的方法3.2.1 測試方法概述應用安全性測試與驗收的方法主要包括： 靜態的代碼安全測試（白盒法）：主要通過對源代碼進行安全掃描，根據程序中數據流、控制流、語義等信息與其特有軟件安全規則庫進行匹對，從中找出代碼中潛在的安全漏洞。該方法非常有用，可在編碼階段找出所有可能存在安全風險的代碼，這樣開發人員可以在早期解決潛在的安全問題。靜態代碼測試更適用于早期的代碼開發階段，而不是測試階段。 動態的滲透測試（黑盒法）：滲透測試也是常用的安全測試方法。是使用自動化工具或者人工的方法模擬黑客的輸入，對應用系統進行攻擊性測試，從中找出運行時刻所存在的安全漏洞。該測試方法的特點是真實有效，一般找出來的問題都是正確的，也是較為嚴重的。但滲透測試一個致命的缺點是模擬的測試數據只能到達有限的測試點，覆蓋率很低。 程序數據掃描：通常是進行內存測試，內存測試可以發現許多諸如緩沖區溢出之類的漏洞，而這類漏洞使用除此之外的測試手段都難以發現。該測試方法主要用于確保有高安全性需求應用在運行過程中的數據安全性。數據掃描通暢需要專門的工具來進行驗證。3.2.2 應用安全測試的成功要素成功的應用安全測試需要做好如下方面的充分準備： 充分了解軟件安全漏洞：評估一個軟件系統的安全程度，需要從設計、實現和部署三個環節同時著手。這一點可參考通用評估準則（Common Criteria）的軟件系統安全評估方法來理解：首先要確定軟件產品對應的Protection Profile（PP,產品的安全特性模板），然后根據PP再提出具體的安全功能需求，最后確定安全對象以及是如何滿足對應的安全功能需求的。因此，一個安全軟件的三個環節，哪個出問題都不行，需要充分了解各環節的軟件安全漏洞。 安全性測試的評估：需要建立對測試后的安全性評估機制，一般可從如下兩個方面進行評估： 安全性缺陷數據評估：直接分析評估目標代碼，如果發現軟件的安全性缺陷和漏洞越多，可能遺留的缺陷也越多。進行這類評估時，必須建立基線數據作為參照，否則評估起來沒有依據就無法得到正確的結論。 采用漏洞植入法來進行評估：通過在目標代碼中植入一些有安全漏洞，然后測試可發現的植入漏洞，并以此來評估軟件的安全性測試做得是否充分。 采用安全測試技術和工具：可使用專業的具有特定功能的安全掃描軟件來尋找潛在的漏洞，將已經發生的缺陷納入缺陷庫，然后通過自動化測試方法來使用自動化缺陷庫進行轟炸測試。3.2.3 反向安全測試與正向安全測試（1）反向安全性測試過程大部分軟件的安全測試都是依據缺陷空間反向設計原則來進行的，即事先檢查哪些地方可能存在安全隱患，然后針對這些可能的隱患進行測試。因此，反向測試過程是從缺陷空間出發，建立缺陷威脅模型，通過威脅模型來尋找入侵點，對入侵點進行已知漏洞的掃描測試。其優點是可對已知的缺陷進行分析，避免軟件里存在已知類型的缺陷；缺點是對未知的攻擊手段和方法通常會無能為力。反向安全性測試的常規過程將包括： 建立缺陷威脅模型。建立缺陷威脅模型主要是從已知的安全漏洞入手，檢查軟件中是否存在已知的漏洞。建立威脅模型時，需要先確定軟件牽涉到哪些專業領域，再根據各個專業領域所遇到的攻擊手段來進行建模。 尋找和掃描入侵點。檢查威脅模型里的哪些缺陷可能在本軟件中發生，再將可能發生的威脅納入入侵點矩陣進行管理。如果有成熟的漏洞掃描工具，那么直接使用漏洞掃描工具進行掃描，然后將發現的可疑問題納入入侵點矩陣進行管理。 入侵矩陣的驗證測試。創建好入侵矩陣后，就可以針對入侵矩陣的具體條目設計對應的測試用例，然后進行測試驗證。（2）正向安全性測試過程為了規避反向設計原則所帶來的測試不完備性，需要一種正向的測試方法來對軟件進行比較完備的測試，使測試過的軟件能夠預防未知的攻擊手段和方法。正向安全性測試過程通常包括： 先標識測試空間。對測試空間的所有的可變數據進行標識，由于進行安全性測試的代價高昂，其中要重點對外部輸入層進行標識。例如，需求分析、概要設計、詳細設計、編碼這幾個階段都要對測試空間進行標識，并建立測試空間跟蹤矩陣。 精確定義設計空間。重點審查需求中對設計空間是否有明確定義，和需求牽涉到的數據是否都標識出了它的合法取值范圍。在這個步驟中，最需要注意的是精確二字，要嚴格按照安全性原則來對設計空間做精確的定義。 標識安全隱患。根據找出的測試空間和設計空間以及它們之間的轉換規則，標識出哪些測試空間和哪些轉換規則可能存在安全隱患。例如,測試空間愈復雜，即測試空間劃分越復雜或可變數據組合關系越多也越不安全。還有轉換規則愈復雜，則出問題的可能性也愈大，這些都屬于安全隱患。 建立和驗證入侵矩陣。安全隱患標識完成后，就可以根據標識出來的安全隱患建立入侵矩陣。列出潛在安全隱患，標識出存在潛在安全隱患的可變數據，和標識出安全隱患的等級。其中對于那些安全隱患等級高的可變數據，必須進行詳盡的測試用例設計。（3）正向和反向測試的區別正向測試過程是以測試空間為依據尋找缺陷和漏洞，反向測試過程則是以已知的缺陷空間為依據去尋找軟件中是否會發生同樣的缺陷和漏洞，兩者各有其優缺點。反向測試過程主要的一個優點是成本較低，只要驗證已知的可能發生的缺陷即可，但缺點是測試不完善，無法將測試空間覆蓋完整，無法發現未知的攻擊手段。正向測試過程的優點是測試比較充分，但工作量相對來說較大。因此，對安全性要求較低的軟件，一般按反向測試過程來測試即可，對于安全性要求較高的軟件，應以正向測試過程為主，反向測試過程為輔。3.2.5 軟件生命周期中的應用安全保證機制*（這部分屬于最終要建立的覆蓋軟件生命周期的安全保證機制，供參考）在保證應用安全的整個生命周期中，需要涉及多個基本任務，這些任務包括： 設置安全需求 (Set Security Requirements)：由安全專家或相關人員指定在項目中哪些問題可以被定義為安全漏洞、每種安全漏洞對項目的影響程度。 配置 (Configure)：針對不同的項目，進行必要的配置以掃描應用。 掃描 (Scan)：掃描項目代碼并返回結果。 優選 (Triage)：根據掃描的結果進行排選，發現影響最大、需要立即修復漏洞的過程。 解決 (Resolve/Remediate)：通過修改代碼、增加安全函數、移出缺陷等方式修復發現的安全漏洞。 驗證 (Verify)：重新掃描代碼以保證安全漏洞已經被正確修復。 企業可以根據規模、人力等因素將這些任務和不同的角色相結合，因此在軟件開發的生命周期中保證應用安全，就會產生如下三種部署模式。在具體應用時，可根據各項目組的實際情況來靈活選擇。（1）簡易模式簡易模式下，相關角色的職責分別為： 管理人員或者安全專家：設置安全需求定義，同時建立驗證標準；在項目過程中查看報告，獲知安全相關的信息； 研發人員：從源代碼控制系統中檢出代碼進行開發；在任何時候都可以自行配置掃描工具進行掃描，并分析掃描結果；決定如何去修復，最后在修復完成后再次運行掃描，來驗證是否修改正確，如果正確，則將代碼檢入到源代碼控制系統，否則繼續進行修改。這種模式的優點是易于實現，僅涉及兩種角色，管理人員和開發人員。非常適合小規模的開發團隊，以及需要進行審計的項目。同時，由于產生交互的環節少，而且由寫代碼的開發人員自己發現問題，可以更有效的優選和解決安全漏洞。該模式的缺點是不適合大規模部署，增大了開發人員的工作量，對開發人員也提出了更高的要求，他們需要了解一定的安全知識。同時，很難將企業的流程和策略加到代碼修復過程中。（2）分布模式該模式將質量管理人員和產品發布團隊納入到應用安全生命周期中。分布模式下，相關角色的職責分別為： 管理人員或安全專家：設置安全需求定義；連接到源代碼控制系統了解開發進度；審閱 QA 團隊提供的評估數據或報告。 QA 團隊或產品發布團隊：進行掃描配置，還可以選擇將掃描工具和現有的 Build 系統集成，實現在構建過程中自動加入應用代碼安全審計的目的；在設定的里程碑時間點，從源代碼控制系統中同步代碼并對其進行安全掃描；將掃描完成的源數據（源數據包括掃描出來的漏洞信息和源代碼的正確版本）發送給開發人員；并將掃描結果形成報告發送給管理團隊。 開發人員：對發送給自己的安全掃描結果進行優選；根據項目需要選擇修復；重新測試以驗證并將正確的代碼檢入到源代碼控制系統。分布模式的優點是部署靈活，可以和 build 過程緊密結合，充分利用自動化的構建過程發現安全漏洞，提高了工作效率，而且 QA 和產品發布人員承擔了一部分的安全診斷工作，減輕了開發人員工作量的同時，使更多的角色參與到應用安全的范疇中。另外，由 QA 團隊集中產生安全評估報告，也能方便管理團隊全面了解企業的應用安全現狀。該模式適合中到大型企業以及希望加入一定控制措施的應用。但是同樣要求開發人員有較強的安全知識。（3）集中模式集中模式下，相關角色的職責分別為： 管理人員或者安全專家：設置安全需求定義；連接到源代碼控制系統了解開發進度；審閱安全分析團隊或 QA 團隊提供的評估數據或報告。 安全分析團隊或 QA 團隊：配置掃描工具，并可以選擇和企業的 build 系統集成；從源代碼控制系統中獲取最新的代碼進行掃描；對掃描結果進行優選；將優選結果根據某種分類打包，提交到企業的缺陷跟蹤系統中；從缺陷跟蹤系統中獲得漏洞修復的最新情況，形成應用安全報告提交給管理團隊； 開發人員：從缺陷跟蹤系統中接受任務，修復代碼；重新測試進行驗證，并將正確結果檢入到源代碼控制系統。集中模式和其它模式的區別主要是開發人員不需要承擔多余的安全分析工作，只將注意力放在和修復其它缺陷一樣進行代碼修復，由安全分析團隊或者 QA 團隊集中承擔安全診斷的工作。這種模式的好處是職責分明，能夠和企業現有的系統，如 build 系統、缺陷跟蹤系統集成，很好的遵循了企業固有工作模式。而且將安全分析工作集中起來，便于企業集中培訓和指導安全人員，使得每個角色在參與到應用安全的同時，不用承擔更多的工作。同時，這種模式部署靈活，非常適合大型開發團隊或者擁有安全專家的企業。4. 常用的安全檢查手段與方法（參考）測評項測評內容測評方法部署與基礎結構 網絡是否提供了安全的通信 部署拓撲結構是否包括內部的防火墻 部署拓撲結構中是否包括遠程應用