項目應用系統(tǒng)開發(fā)安全管理規(guī)范標準

1、WORD 專業(yè)資料. WORD 專業(yè)資料. 文檔編號：項目應用開發(fā)等級保護規(guī)密級：項目部項目應用系統(tǒng)開發(fā)安全管理規(guī)（信息系統(tǒng)等級保護三級）DATE EEEE年O月 * MERGEFORMAT二二一年一月編 號 應用開發(fā)等級保護規(guī)密 級項目部 階 段項目設計階段 頁 數(shù)代號 名稱建設單位承建單位會 簽編 寫校 對審 核標 審批 準關于本文檔說明：類型創(chuàng)建（C）、修改（U）、刪除（D）、增加（A）；目 錄TOC o 1-3 h z uHYPERLINK l _Toc331408056第1章 概述 PAGEREF _Toc331408056 h 1HYPERLINK l _Toc3314080571

2、.1目標 PAGEREF _Toc331408057 h 1HYPERLINK l _Toc3314080581.2適用圍 PAGEREF _Toc331408058 h 1HYPERLINK l _Toc3314080591.3規(guī)引用的文件或標準 PAGEREF _Toc331408059 h 2HYPERLINK l _Toc3314080601.4術(shù)語和定義 PAGEREF _Toc331408060 h 2HYPERLINK l _Toc3314080611.5應用系統(tǒng)開發(fā)總體原則 PAGEREF _Toc331408061 h 3HYPERLINK l _Toc331408062第2

3、章 系統(tǒng)需求收集和分析階段 PAGEREF _Toc331408062 h 5HYPERLINK l _Toc3314080632.1可行性研究分析 PAGEREF _Toc331408063 h 5HYPERLINK l _Toc3314080642.1.1技術(shù)可行性分析 PAGEREF _Toc331408064 h 5HYPERLINK l _Toc3314080652.1.2需求可行性分析 PAGEREF _Toc331408065 h 5HYPERLINK l _Toc3314080662.1.3投資可行性分析 PAGEREF _Toc331408066 h 5HYPERLINK l

4、 _Toc3314080672.1.4影響可行性分析 PAGEREF _Toc331408067 h 5HYPERLINK l _Toc3314080682.2開發(fā)人員安全管理 PAGEREF _Toc331408068 h 6HYPERLINK l _Toc3314080692.2.1系統(tǒng)開發(fā)人員職責分配 PAGEREF _Toc331408069 h 6HYPERLINK l _Toc3314080702.2.2開發(fā)人員授權(quán) PAGEREF _Toc331408070 h 6HYPERLINK l _Toc3314080712.2.3開發(fā)人員必須訓練開發(fā)安全代碼的能力 PAGEREF _T

5、oc331408071 h 6HYPERLINK l _Toc3314080722.2.4分離系統(tǒng)開發(fā)和運作維護 PAGEREF _Toc331408072 h 7HYPERLINK l _Toc3314080732.3建立系統(tǒng)開發(fā)安全需求分析報告 PAGEREF _Toc331408073 h 7HYPERLINK l _Toc331408074第3章 系統(tǒng)設計階段的安全規(guī) PAGEREF _Toc331408074 h 8HYPERLINK l _Toc3314080753.1單點訪問控制且無后門 PAGEREF _Toc331408075 h 8HYPERLINK l _Toc33140

6、80763.2人員職責和權(quán)限的定義 PAGEREF _Toc331408076 h 8HYPERLINK l _Toc3314080773.3確保敏感系統(tǒng)的安全性 PAGEREF _Toc331408077 h 8HYPERLINK l _Toc3314080783.4確保訪問層的安全性 PAGEREF _Toc331408078 h 8HYPERLINK l _Toc3314080793.5確保日志管理機制健全 PAGEREF _Toc331408079 h 8HYPERLINK l _Toc3314080803.6新系統(tǒng)的容量規(guī)劃 PAGEREF _Toc331408080 h 9HYPE

7、RLINK l _Toc331408081第4章 系統(tǒng)開發(fā)階段安全規(guī) PAGEREF _Toc331408081 h 10HYPERLINK l _Toc3314080824.1系統(tǒng)開發(fā)語言 PAGEREF _Toc331408082 h 10HYPERLINK l _Toc3314080834.1.1通用規(guī) PAGEREF _Toc331408083 h 10HYPERLINK l _Toc3314080844.1.2Perl語言 PAGEREF _Toc331408084 h 11HYPERLINK l _Toc3314080854.1.3Java語言 PAGEREF _Toc331408

8、085 h 13HYPERLINK l _Toc3314080864.1.4C/C+語言 PAGEREF _Toc331408086 h 14HYPERLINK l _Toc3314080874.2系統(tǒng)開發(fā)安全相關工具管理 PAGEREF _Toc331408087 h 17HYPERLINK l _Toc3314080884.2.1工具一：Pscan PAGEREF _Toc331408088 h 18HYPERLINK l _Toc3314080894.2.2工具二：Flawfinder PAGEREF _Toc331408089 h 18HYPERLINK l _Toc331408090

9、4.3控制軟件代碼程序庫 PAGEREF _Toc331408090 h 19HYPERLINK l _Toc3314080914.3.1管理運作程序庫 PAGEREF _Toc331408091 h 19HYPERLINK l _Toc3314080924.3.2管理源程序庫 PAGEREF _Toc331408092 h 19HYPERLINK l _Toc3314080934.4在軟件開發(fā)過程變更管理 PAGEREF _Toc331408093 h 20HYPERLINK l _Toc3314080944.5開發(fā)版本管理 PAGEREF _Toc331408094 h 21HYPERLI

10、NK l _Toc3314080954.5.1控制程序清單 PAGEREF _Toc331408095 h 21HYPERLINK l _Toc3314080964.5.2版本升級控制 PAGEREF _Toc331408096 h 21HYPERLINK l _Toc3314080974.5.3版本變更控制 PAGEREF _Toc331408097 h 22HYPERLINK l _Toc3314080984.6開發(fā)日志審核管理 PAGEREF _Toc331408098 h 22HYPERLINK l _Toc3314080994.6.1開發(fā)日志定期審計 PAGEREF _Toc3314

11、08099 h 22HYPERLINK l _Toc3314081004.6.2開發(fā)人員權(quán)限定期審計 PAGEREF _Toc331408100 h 22HYPERLINK l _Toc3314081014.7防御后門代碼或隱藏通道 PAGEREF _Toc331408101 h 22HYPERLINK l _Toc3314081024.7.1后門代碼和隱藏通道介紹 PAGEREF _Toc331408102 h 22HYPERLINK l _Toc3314081034.7.2防御后門代碼和隱藏通道的相關辦法 PAGEREF _Toc331408103 h 23HYPERLINK l _Toc

12、331408104第5章 系統(tǒng)測試階段安全規(guī) PAGEREF _Toc331408104 h 24HYPERLINK l _Toc3314081055.1應用系統(tǒng)的安全性檢測 PAGEREF _Toc331408105 h 24HYPERLINK l _Toc3314081065.1.1設計詳細的測試計劃、測試圍、測試方法和測試工具 PAGEREF _Toc331408106 h 24HYPERLINK l _Toc3314081075.1.2測試種類 PAGEREF _Toc331408107 h 24HYPERLINK l _Toc3314081085.1.3在測試的過程中詳細描述每個和測

13、試方案相關的測試步驟和測試數(shù)據(jù) PAGEREF _Toc331408108 h 26HYPERLINK l _Toc3314081095.2控制測試環(huán)境 PAGEREF _Toc331408109 h 26HYPERLINK l _Toc3314081105.3為測試使用真實的數(shù)據(jù) PAGEREF _Toc331408110 h 26HYPERLINK l _Toc3314081115.4在軟件轉(zhuǎn)移至生產(chǎn)環(huán)境前進行測試 PAGEREF _Toc331408111 h 27HYPERLINK l _Toc3314081125.5應用系統(tǒng)安全質(zhì)量鑒定 PAGEREF _Toc331408112 h

14、 27HYPERLINK l _Toc331408113第6章 系統(tǒng)培訓與文檔階段安全規(guī) PAGEREF _Toc331408113 h 28HYPERLINK l _Toc3314081146.1新系統(tǒng)的培訓 PAGEREF _Toc331408114 h 28HYPERLINK l _Toc3314081156.2撰寫新系統(tǒng)和系統(tǒng)改進的文檔 PAGEREF _Toc331408115 h 28HYPERLINK l _Toc331408116第7章 應用系統(tǒng)開發(fā)外包安全控制 PAGEREF _Toc331408116 h 29HYPERLINK l _Toc331408117第8章 附錄

15、PAGEREF _Toc331408117 h 30HYPERLINK l _Toc3314081188.1參考文獻 PAGEREF _Toc331408118 h 30HYPERLINK l _Toc3314081198.2本規(guī)用詞說明 PAGEREF _Toc331408119 h 32HYPERLINK l _Toc3314081208.2.1為便于在執(zhí)行本規(guī)條文時區(qū)別對待，對要求嚴格程度不同的用詞說明如下： PAGEREF _Toc331408120 h 32HYPERLINK l _Toc3314081218.2.2條文中指定應按其它有關標準、規(guī)執(zhí)行時，寫法為“應符合的規(guī)定”或“應按

16、要求（或規(guī)定）執(zhí)行”。 PAGEREF _Toc331408121 h 32概述信息系統(tǒng)的許多的安全控制或其他安全性保證是通過系統(tǒng)的開發(fā)設計予以實現(xiàn)的。因此如果在系統(tǒng)的開發(fā)設計階段沒有對系統(tǒng)的安全性給予充分的考慮，那么系統(tǒng)本身一定會存在許多先天不足，系統(tǒng)就會漏洞百出。為確保應用系統(tǒng)的安全，在應用系統(tǒng)開發(fā)之前就應確認系統(tǒng)的安全需求，并以此作為開發(fā)設計的階段的基礎。本規(guī)主要規(guī)定了在系統(tǒng)開發(fā)的各個階段所應遵守的各種安全規(guī)，從需求分析開始，到設計，再到開發(fā)和維護以與最后的文檔等系統(tǒng)開發(fā)的各個階段分別進行闡述，并將在不同階段中所需要注意的安全問題和相關的安全規(guī)進行進一步的描述和規(guī)定。目標保護應用系統(tǒng)開發(fā)

17、過程的安全。具體地說就是保護應用系統(tǒng)開發(fā)過程免受未經(jīng)授權(quán)的訪問和更改，保護系統(tǒng)開發(fā)中系統(tǒng)軟件和信息的安全，確保開發(fā)項目順利正確的實施并對開發(fā)環(huán)境進行嚴格的控制。同時確保應用系統(tǒng)開發(fā)外包中的各項安全。適用圍本套規(guī)適用的圍包括了整個應用系統(tǒng)開發(fā)過程中的安全。包括了系統(tǒng)開發(fā)可行性和需求分析階段的安全，系統(tǒng)設計階段的安全，系統(tǒng)開發(fā)階段的安全，系統(tǒng)測試階段的安全，系統(tǒng)培訓和文檔階段的安全以與系統(tǒng)開發(fā)外包的安全規(guī)。主要規(guī)定了應用系統(tǒng)開發(fā)過程的安全，軟件的質(zhì)量的要求，系統(tǒng)和業(yè)務需求的符合性，保證敏感信息的安全，系統(tǒng)本身的穩(wěn)定性和兼容性問題。規(guī)引用的文件或標準下列文件中的條款通過本標準的引用而成為本標準的條款

18、。凡是不注日期的引用文件，其最新版本適用于本標準。GB17859-1999 計算機信息系統(tǒng)安全保護等級劃分準則GB/T 9387-1995 信息處理系統(tǒng) 開放系統(tǒng)互連基本參考模型（ISO7498 :1989）GA/T 391-2002 計算機信息系統(tǒng)安全等級保護管理要求ISO/IEC TR 13355 信息技術(shù)安全管理指南NIST信息安全系列美國國家標準技術(shù)院英國國家信息安全標準BS7799信息安全基礎保護IT Baseline Protection Manual (Germany)BearingPoint Consulting 部信息安全標準RU Secure安全技術(shù)標準信息系統(tǒng)安全專家叢書

19、Certificate Information Systems Security Professional術(shù)語和定義訪問控制access control 一種安全保證手段，即信息系統(tǒng)的資源只能由被授權(quán)實體按授權(quán)方式進行訪問，防止對資源的未授權(quán)使用。應用系統(tǒng) application system認證 authentication a. 驗證用戶、設備和其他實體的身份； b. 驗證數(shù)據(jù)的完整性。授權(quán)authorization 給予權(quán)利，包括信息資源訪問權(quán)的授予?？捎眯詀vailability 數(shù)據(jù)或資源的特性，被授權(quán)實體按要求能與時訪問和使用數(shù)據(jù)或資源。緩沖器溢出 buffer overflow指

20、通過往程序的緩沖區(qū)寫超出其長度的容，造成緩沖區(qū)的溢出，從而破壞程序的堆棧，使程序轉(zhuǎn)而執(zhí)行其它指令，以達到攻擊的目的。性confidentiality 數(shù)據(jù)所具有的特性，即表示數(shù)據(jù)所達到的未提供或未泄露給未授權(quán)的個人、過程或其他實體的程度。隱藏通道 covert channel 可用來按照違反安全策略的方式傳送!數(shù)據(jù)的傳輸信道。完整性integrity在防止非授權(quán)用戶修改或使用資源和防止授權(quán)用戶不正確地修改或使用資源的情況下,信息系統(tǒng)中的數(shù)據(jù)與在原文檔中的一樣，并未遭受偶然或惡意的修改或破壞時所具的性質(zhì)。敏感信息 sensitive information 由權(quán)威機構(gòu)確定的必須受保護的信息，因為

21、該信息的泄露、修改、破壞或丟失都會對人或事產(chǎn)生可預知的損害。系統(tǒng)測試 system testing用于確定系統(tǒng)的安全特征按設計要現(xiàn)的過程。這一過程包括現(xiàn)場功能測試、滲透測試和驗證。后門代碼 trapdoor 通常為測試或查找故障而設置的一種隱藏的軟件或硬件機制，它能避開計算機安全。而且它能在非常規(guī)時間點或無需常規(guī)檢查的情況下進入程序。特洛伊木馬Trojan horse一種表面無害的程序，它包含惡性邏輯程序，導致未授權(quán)地收集、偽造或破壞數(shù)據(jù)，以此破壞計算機安全與完整性的進程。驗證 verification 將某一活動、處理過程或產(chǎn)品與相應的要求或規(guī)相比較。例：將某一規(guī)與安全策略模型相比較，或者將

22、目標代碼與源代碼相比較。壓力測試 于確定系統(tǒng)的薄弱環(huán)節(jié)，確定系統(tǒng)在非正常條件下能夠迅速恢復到正常的運行狀態(tài)的能力。應用系統(tǒng)開發(fā)總體原則應用系統(tǒng)的開發(fā)應遵循一系列的總體原則，以確保開發(fā)過程中的安全。其中包括：系統(tǒng)開發(fā)應從業(yè)務需求的角度出發(fā)，不得盲目追求系統(tǒng)的先進性而忽略了系統(tǒng)的實用性。系統(tǒng)的開發(fā)是為了更好地滿足業(yè)務上的需要，而不是技術(shù)上的需要。開發(fā)的方法和管理必須規(guī)化、合理化、制度化，從而確保開發(fā)的質(zhì)量和進度。應保證開發(fā)的進度并按時完成。確保開發(fā)工作與時、有效且高質(zhì)量的完成。系統(tǒng)開發(fā)必須具有一定的前瞻性，符合主流系統(tǒng)的發(fā)展方向。提高和加強開發(fā)人員的安全意識。確保信息和關鍵技術(shù)不會泄漏，特別是不可

23、泄漏到競爭對手的手中，否則將會對公司的競爭力產(chǎn)生極大的影響。應充分利用現(xiàn)有的資源。系統(tǒng)需求收集和分析階段可行性研究分析對于應用系統(tǒng)開發(fā)項目應進行一定的可行性分析，以保證只有在確認具備了相當?shù)馁Y源和條件，并且有能力滿足業(yè)務上的需求的情況下才能開展開發(fā)工作。切忌盲目開發(fā)，否則既浪費資源，又浪費時間?？尚行匝芯恳藦募夹g(shù)、需求面、投入和影響四個方面進行考慮：技術(shù)可行性分析根據(jù)業(yè)務上提出的需求，從技術(shù)開發(fā)的角度分析現(xiàn)有的技術(shù)手段和技術(shù)能力是否能夠?qū)崿F(xiàn)業(yè)務上所要求的系統(tǒng)功能。通?？蓮囊韵氯齻€方面進行分析：人員技術(shù)能力分析，指公司的系統(tǒng)開發(fā)隊伍或外包的第三方開發(fā)公司是否具有足夠技術(shù)和管理能力來完成系統(tǒng)開發(fā)的

24、任務。計算機軟件和硬件分析，指公司現(xiàn)有的軟件和硬件的性能是否足夠滿足開發(fā)相應的系統(tǒng)的要求。管理能力分析，指現(xiàn)有的技術(shù)開發(fā)管理制度和管理流程是否成熟且標準化，是否滿足系統(tǒng)開發(fā)的要求。需求可行性分析系統(tǒng)的開發(fā)來源于業(yè)務上的需求，因此需要對該需求進行可行性分析，以判斷需否明確，是否符合實際，是否在一定的時間圍可以實現(xiàn)。投資可行性分析根據(jù)業(yè)務需求和技術(shù)手段的分析，確認實現(xiàn)系統(tǒng)開發(fā)所需的投資，并確認投資的數(shù)額是否在可控制和可承受的圍。影響可行性分析所謂的影響是指社會影響，比如系統(tǒng)開發(fā)是否符合法律法規(guī)上的要求，是否和相關的管理制度或行業(yè)標準相抵觸，是否符合人文或道德上的約束等。開發(fā)人員安全管理系統(tǒng)開發(fā)人員

25、職責分配在系統(tǒng)開發(fā)的過程中，應明確不同人員的身份和職責。在系統(tǒng)開發(fā)過程中具體可分以下三種角色：項目負責人員：確保在整個系統(tǒng)開發(fā)的各個階段都實施了相關的安全措施，同時在整個系統(tǒng)開發(fā)的過程中負責整個項目的開發(fā)安全管理。系統(tǒng)開發(fā)人員：根據(jù)業(yè)務需求確保開發(fā)的系統(tǒng)能夠滿足業(yè)務上的需求和相應的安全上的需求，同時滿足系統(tǒng)質(zhì)量上和進度上的要求。系統(tǒng)審核人員：對整個開發(fā)的過程進行審核和監(jiān)督，確保開發(fā)的質(zhì)量和開發(fā)的安全。開發(fā)人員授權(quán)應根據(jù)該員工在整個開發(fā)項目中所負責的開發(fā)容授予其相應的權(quán)限和所應承擔的責任。開發(fā)人員必須負責其開發(fā)容的性，不得私自將開發(fā)的相關信息泄漏出去，即使對家人或開發(fā)團隊中的其他開發(fā)人員也不得泄

26、漏。但開發(fā)人員有責任將開發(fā)的相關信息告訴項目的負責人員或開發(fā)小組的負責人員。以書面的方式將員工的權(quán)限和相應的責任提交給員工本人。必須嚴格規(guī)定在為企業(yè)工作期間，所有和工作相關的開發(fā)成果的所屬權(quán)都歸企業(yè)所有。應根據(jù)員工權(quán)限和責任的大小確認是否需要簽署相關的協(xié)議。應在日常工作中記錄員工與開發(fā)相關的日志信息。員工一旦離職或調(diào)動崗位應立即收回或調(diào)整其相應的權(quán)限。開發(fā)人員必須訓練開發(fā)安全代碼的能力在整個開發(fā)的過程中必須完整持續(xù)地進行代碼錯誤處理所規(guī)定的流程。錯誤問題報告應力求通俗易懂，不應在其中包含任何系統(tǒng)細節(jié)問題。應對重要的敏感信息進行加密保護。應使用一些相對復雜的加密和密鑰生成機制。應單獨編寫安全性設

27、計說明概要分離系統(tǒng)開發(fā)和運作維護管理層必須確保應用系統(tǒng)的開發(fā)和運作管理從組織人事和權(quán)限職責上分開。信息技術(shù)人員可以現(xiàn)場修復或更改偶然或惡意的數(shù)據(jù)和軟件問題。測試代碼中往往包含調(diào)試或者查錯代碼，大大增加了主機系統(tǒng)的性能負擔。開發(fā)人員不應具有很高的權(quán)限，否則將在系統(tǒng)運行中產(chǎn)生很大的風險。建立系統(tǒng)開發(fā)安全需求分析報告安全需求計劃應能夠達到期望的安全水平。其中包括了成本的預估，完成各個安全相關流程所需的時間。所有關于應用系統(tǒng)的更新或改進都必須基于業(yè)務需求，并有業(yè)務事件支持。這里的業(yè)務需求不僅僅包括了系統(tǒng)的功能、性能、開發(fā)費用、開發(fā)周期等容，應明確系統(tǒng)的安全要求。應用系統(tǒng)的任何一次改進或更新都應和該業(yè)務

28、系統(tǒng)的所有者密切相關。開發(fā)安全需求分析計劃應由開發(fā)項目經(jīng)理和公司部的安全小組共同商議決定。應確保每一個應用系統(tǒng)的用戶都意識到系統(tǒng)的更新或改進都與其自身密切相關，所有的更新或改動建議都必須基于業(yè)務需求，而不是基于所謂的“信息技術(shù)的要求”。系統(tǒng)的每一次更新或改進都必須認真對待，必須進行詳細的需求定義、需求分析以與測試評估，以保證不會對業(yè)務造成任何不良影響。業(yè)務需系統(tǒng)更新和改動的基礎，因此必須清晰明確地定義業(yè)務的需求，禁止在業(yè)務需求未經(jīng)業(yè)務部門領導和主要負責人員認可的情況下，盲目地進行開發(fā)工作。系統(tǒng)設計階段的安全規(guī)單點訪問控制且無后門任何用戶如果希望訪問應用系統(tǒng)中的某一部分，則必須通過統(tǒng)一且唯一的認

29、證授權(quán)方式與流程。人員職責和權(quán)限的定義由于不是所有的人員對于某一個應用系統(tǒng)都具有同樣的訪問或使用權(quán)限，因此系統(tǒng)必須具有基于人員職責的用戶授權(quán)管理，以確保每個用戶可以訪問到其權(quán)限圍的應用系統(tǒng)部分。同時應確保每個用戶無法訪問其權(quán)限圍以外的應用系統(tǒng)部分。確保敏感系統(tǒng)的安全性將應用系統(tǒng)中敏感的信息保存在服務器端以進行集中的加密的安全管理，確?？蛻舳讼到y(tǒng)本身并不能存儲任何敏感的數(shù)據(jù)。確保訪問層的安全性應用系統(tǒng)不僅僅要確保系統(tǒng)模塊本身的安全性，同時還應考慮模塊與模塊之間通訊的安全性。這種模塊與模塊之間通訊的安全性不僅僅包括了應用系統(tǒng)部模塊之間通訊的安全，也包括了應用系統(tǒng)部模塊和外部模塊之間的通訊安全性，如

30、主機和客戶端之間通訊的安全性、服務器和服務器間通訊的安全性，以與本地系統(tǒng)和異地系統(tǒng)之間通訊的安全性。確保日志管理機制健全應建立可根據(jù)情況自由設置的日志管理機制，也就是說日志記錄的圍和詳細程度可以根據(jù)需求自行定制，且可以實現(xiàn)在應用系統(tǒng)的使用過程中進行日志的定制和記錄。保留所有與系統(tǒng)開發(fā)相關的程序庫的更新審核記錄。新系統(tǒng)的容量規(guī)劃容量規(guī)劃是指確定系統(tǒng)的總體規(guī)模、性能和系統(tǒng)彈性。容量規(guī)劃的具體容可能有所不同，但一般應考慮以下方面：系統(tǒng)的預期存儲容量和在給定的周期中獲取生成和存儲的數(shù)據(jù)量。在線進程的數(shù)量和估計可能的占用資料系統(tǒng)和網(wǎng)絡的響應時間和性能，即端對端系統(tǒng)系統(tǒng)彈性要求和設計使用率（峰值，槽值和平

31、均值等）安全措施如加密解密數(shù)據(jù)對系統(tǒng)的影響。24x7運作要求和可接受的系統(tǒng)宕機次數(shù)（維護或者設備更新導致的必須性宕機）規(guī)劃容量的時候關于系統(tǒng)使用的信息了解的越多越好。近來，由于互聯(lián)的使用以指數(shù)形式增長，容量規(guī)劃的變動效果不是非常顯著，有時甚至毫無用處。原因在于很難估計實際的負載。在容量估計的時候應盡量將情況設想得復雜一些。系統(tǒng)開發(fā)階段安全規(guī)系統(tǒng)開發(fā)語言程序員可使用很多指導規(guī)來防止應用程序中的普通安全問題。其中許多可以應用于任何一種編程語言，但某些是針對特定的語言的。特定語言的指導規(guī)主要集中在Perl，Java和C/C+語言。大多數(shù)情況下，一般的錯誤可以避免。而這些本可以避免的錯誤常常會導致很多

32、安全漏洞，從而威脅信息的性、完整性和可用性。通用規(guī)輸入驗證在客戶機/服務器環(huán)境下，進行服務端的驗證而不是客戶端的驗證（例如基于Javascript的驗證）。通過在客戶端和服務器之間放置一個代理服務器，可以很容易繞過客戶端驗證。有了代理服務器，攻擊者可以在數(shù)據(jù)被客戶端“驗證”后修改數(shù)據(jù)（與“man-in-the-middle”攻擊類似）。在實際的校驗中，輸入校驗首先定義一個有效（可接受）的字符集，然后檢查每個數(shù)據(jù)的字符是否在有效圍。如果輸入中包含無效的字符，應用程序應返回錯誤頁面并說明輸入中包含無效字符。這樣進行驗證的原因是定義無效的字符集比較困難，并且一些不應有效的字符通常不會被指出。邊界檢查

33、（例如字符串的最大長度）應在字符有效性檢查以前進行。邊界分析可以防止大多數(shù)緩沖區(qū)溢出漏洞。從環(huán)境變量獲得的數(shù)據(jù)也需要進行驗證。同時避免在環(huán)境變量中存放敏感數(shù)據(jù)（例如密碼）。某些Unix系統(tǒng)（例如FreeBSD）包含ps命令，可以讓用戶看到任何當前進程的環(huán)境變量，這常常會暴露性信息。SQL語句如果應用程序需要連接后端數(shù)據(jù)庫，不得在代碼中使用SQL語句。使用程序以外的嵌入在代碼中的SQL語句調(diào)用特別危險，難以防止攻擊者使用輸入域或者配置文件（由應用程序載入）來執(zhí)行嵌入式的SQL攻擊。而輸入驗證有助于緩解這種風險。注釋代碼(commented code)當應用程序在實際環(huán)境中開始應用時，應刪除所有的

34、注釋代碼。注釋代碼是用來調(diào)試或者測試的，它們不是最終應用程序的一部分。無論如何應在實際的環(huán)境中刪除它們來避免意外的執(zhí)行（一般注釋標識被刪除后就無法激活休眠的代碼，但還是存在可能性的，所以應執(zhí)行這項工作）。錯誤消息所有對用戶顯示的錯誤信息都不應暴露任何關于系統(tǒng)、網(wǎng)絡或應用程序的敏感信息。如果可能的話，應使用包含編號的一般的錯誤信息，這種信息只有開發(fā)者和/或支持小組才能理解。一般的錯誤信息的例子是“發(fā)生了錯誤（代碼1234），請您與系統(tǒng)維護部門聯(lián)系?！苯y(tǒng)一資源定位（URL）容對于web應用，不要在URL上暴露任何重要信息，例如密碼、服務器名稱、IP地址或者文件系統(tǒng)路徑（暴露了web服務器的目錄結(jié)構(gòu)

35、）。這些信息可以在攻擊時使用。例如下面就是一個不安全的URL：.xyzcompany./index.cgi?username=USER&password=PASSWORD&file=/home/USER/expenses.txt設置PATH變量設置PATH為一個已知的值，而不僅僅是使用啟動時的缺省值。攻擊者可以在攻擊應用程序時使用PATH變量，例如試圖執(zhí)行一個任意的程序。這些也可以應用于大多數(shù)其他的語言。Perl語言多年以來，Perl已經(jīng)成為用于系統(tǒng)管理和Web CGI開發(fā)的功能最強的編程語言之一（幾乎可以使用Perl實現(xiàn)任何功能）。但其擴展應用，即作為Internet上CGI的開發(fā)工具，使得

36、它經(jīng)常成為web服務器上的攻擊目標。另外，大多數(shù)CGI腳本有著比一般用戶更高的權(quán)限，導致它更容易受攻擊。下面列舉了一些開發(fā)者（特別是CGI程序員）可以使用的主動的預防性的措施來增強Perl代碼的整體安全性（請注意：這不是web服務器CGI腳本安全性的指導原則）。Taint驗證Perl版本5.x包含一個叫做Taint Checking的數(shù)據(jù)驗證措施。如果起用該功能，它就不允許通過用戶輸入（任何程序外的輸入）來操縱其他的外部程序（例如通過管道將數(shù)據(jù)導入另一個程序執(zhí)行）。一般而言，程序員不能信任輸入腳本和程序的數(shù)據(jù)（叫做Tainted數(shù)據(jù)），因為無法保證它不會產(chǎn)生危害（有意或者無意的）。Taint驗

37、證可以通過在命令行參數(shù)加入“-T”來開啟。例如可以Perl腳本的第一行這樣加入“-T”：#!usr/bin/perl5 -T Tainted數(shù)據(jù)包括命令行參數(shù)、環(huán)境變量和來自文件的數(shù)據(jù)。引用tainted數(shù)據(jù)的變量也成為tainted數(shù)據(jù)。如果腳本試圖通過不安全的方式來使用tainted數(shù)據(jù)會產(chǎn)生一個致命錯誤（對這種情況稱為“不安全的依賴”(Insecure dependency)或者其他的說法）。啟用tainted驗證在有些情況下會導致腳本停止運行，常常是由于Perl解釋器要求所有腳本引用的外部程序的完全路徑必須在PATH環(huán)境變量中列出，同時PATH中包含的每個目錄除了目錄的所有者與相應的所

38、有者用戶組外無法修改。Taint驗證對于環(huán)境比較敏感，這就可能會導致大多數(shù)程序員不愿使用它，但是只要可能就應使用taint驗證，特別是代碼執(zhí)行其他程序功能時（例如在CGI腳本的情況下）。安全模塊如果不但輸入數(shù)據(jù)不可信而且實際的代碼也不可信會產(chǎn)生什么情況？例如用戶從上下載了一個ActiveX控件，而它實際是一個特洛伊木馬(Trojan horse)。這種情況下taint驗證就不起作用。安全模塊讓程序員可以在Perl腳本中將不同的代碼模塊與安全對象相聯(lián)系。每個安全對象對于運行的每塊代碼建立了一個限制的環(huán)境。這與chroot在一個進程中只能在整體目錄結(jié)構(gòu)的一個子目錄中運行類似。而saft對象限制pe

39、rl代碼只能在perl包結(jié)構(gòu)的某些特定包中運行。如何使用安全模式超出了本文的圍，但程序員應在任何時候使用這一功能。警告參數(shù)(-w)使用-w參數(shù)可以在Perl解釋腳本時顯示所有的警告信息。警告可以對以下情況產(chǎn)生：只使用了一次的變量或者完全沒有使用過的變量，未定義的文件句柄，未關閉的文件句柄，或?qū)⒎菙?shù)值變量傳遞到數(shù)據(jù)變量。該功能不是針對安全處理的，但是有助于調(diào)試直接或者間接對安全有危害的錯誤。一般推薦總是使用-w參數(shù)。可在taint驗證時在第一行這樣使用-w參數(shù)：#!usr/bin/perl5 TwJava語言自從1995年發(fā)布以來，Java成為簡單或者復雜網(wǎng)絡應用的有效編程語言。它在設計時充分考

40、慮了安全問題，因此它具有的限制特征有：收集不再使用的存碎片的垃圾收集器，嚴格的“sandbox”安全模型，以與在特定主機上限制應用程序的活動的安全管理器。以下為使用中的相關的規(guī)：不應在標準輸出上打印消息在實際的Internet系統(tǒng)中避免使用System.out.println()或者System.err.println()打印日志和錯誤消息，原因是當消息打印到標準輸出時，無法立即確定消息發(fā)生的地點，且有可能將敏感信息透露給攻擊者。封裝Java中，如果沒有使用訪問標識符(access modifier(private、protected或public)來聲明類、方法和屬性，那么它的默認訪問圍是包

41、，并且同一包中的所有類都能訪問它。必須記住雖然包有封裝功能，但它只有在每部分加載到包的代碼都由授權(quán)用戶控制時才起作用。惡意的用戶可以加入他們自己的類，從而對于包中的所有類、方法和屬性都有完全的訪問權(quán)限。Java的政策文件支持兩種控制包訪問權(quán)限的前綴。accessClassInPackage defineClassInPackage 所有標準庫中的類都默認是可以公共訪問的（除了由“sun”開頭的類）。為了保證一個包的安全性，必須修改$JAVA HOME/jre/lib/security文件夾中的java.security文件。該文件中的重要行是：package.access=sun.雖然該方法有

42、作用，但仍存在問題。例如程序員在java.security文件中定義包的安全時必須十分小心。在package.access中的值是字符型的，“sun.”將保護“sun.tools”等包，但是不會對“sun”或者“sunshine”等包進行保護。另一個方法是使用JAR密封(sealing) 。JAR(Java ARchive)文件是一些類的打包壓縮格式的文件，與常用的ZIP格式類似。如果從一個密封(sealing)的JAR文件中加載一個類，隨后同一個包的類只能從該JAR文件加載。為了起用密封(sealing)，必須在建立JAR文件時這樣設置密封(seal)參數(shù)：Sealed: true 使用密封

43、(sealing)的JAR文件比權(quán)限 (permission) 設置更好，因為它不需要安裝安全管理器(security manager)。政策文件Java建的安全管理器是對應用程序進行限制的一個方便的工具。很多情況下需要編制一個定制的安全管理器，JDK1.2與以后的版本提供了描述設置的方法而不是實施它們。這是通過Java政策文件實現(xiàn)的。可以用政策文件以相對模塊化的方式控制文件系統(tǒng)和網(wǎng)絡的訪問。例如可以限制應用程序只能修改名字是foo的文件。宜使用Java政策文件和安全管理器而不是重新創(chuàng)建一個類或者系統(tǒng)來限制對主機和網(wǎng)絡的訪問。C/C+語言C本質(zhì)上是不安全的編程語言。例如如果不謹慎使用的話，其大

44、多數(shù)標準的字符串庫函數(shù)有可能被用來進行緩沖區(qū)攻擊或者格式字符串攻擊。但是，由于其靈活性、快速和相對容易掌握，它是一個廣泛使用的編程語言。下面是針對開發(fā)安全的C語言程序的一些規(guī)。緩沖區(qū)溢出避免使用不執(zhí)行邊界檢查的字符串函數(shù)，因為它們可能被用來進行緩沖區(qū)溢出攻擊。下面是應避免使用的函數(shù)。同時，也列出了每個函數(shù)相應的比較安全的替換方式。不使用strcpy()，使用strncpy()不使用strcat()，使用strncat()不使用sprintf()，使用snprintf()不使用gets()，使用fgets()在上面的前三個中函數(shù)中，每個替代函數(shù)的“n”表示了使用的緩沖區(qū)的大小。最后一個函數(shù)的“f

45、”，表示格式，它允許用戶指定期望的輸入的格式。這些替換方程強制程序員定義使用的緩沖區(qū)的尺寸以與確定輸入的類型。格式化字符串攻擊（Format String Attack）該類攻擊往往與緩沖區(qū)溢出相關，因為它們往往主要利用了某些函數(shù)的假設，例如sprintf()和vsprintf()假設緩沖區(qū)的長度是無限的。然而即使使用snprintf()替換sprintf()也無法完全保護程序不受格式化字符串的攻擊。這些攻擊通過直接將格式說明符（format specifiers）(%d，%s，%n等)傳遞到輸出函數(shù)接收緩沖區(qū)來進行。例如，以下的代碼就是不安全的：snprintf(buffer, sizeof

46、(buffer), string) 這種情況下，可以在字符串中插入格式說明符來操縱存的棧，來寫入攻擊者的數(shù)據(jù)（這些數(shù)據(jù)中包含小的程序代碼，并可由處理器接著執(zhí)行）。 更多關于這些攻擊的具體容請見資源章節(jié)。對以上的例子建議使用下面的代碼。snprintf(buffer, sizeof(buffer), “%s”, string) 進行格式字符串攻擊不太容易。首先攻擊者必須能獲得存棧的容情況（從應用導出或者使用調(diào)試器），然后必須知道如何精確訪問特定的存空間來操縱棧中的變量。執(zhí)行外部程序推薦使用exec()函數(shù)而不是system()函數(shù)來執(zhí)行外部程序。這是因為system()接收整個命令行的隨機的緩沖

47、區(qū)來執(zhí)行程序。snprintf(buffer, sizeof(buffer), emacs %s, filename); system(buffer);在以上的例子中，可以通過使用分號利用文件名變量在sehll中插入額外的命令（例如文件名可以是/etc/hosts; rm *，這將在顯示/etc/hosts目錄文件的同時，刪除目錄中的所有文件）。而exec()函數(shù)只保證第一個參數(shù)被執(zhí)行：execl(usr/bin/emacs, usr/bin/emacs, filename, NULL);上面的例子保證文件名僅僅作為一個參數(shù)輸入Emacs工具，同樣它在Emacs命令中使用完全的路徑而不是使用可

48、以被攻擊者利用的PATH環(huán)境變量。競爭條件（race condition）進程需要訪問資源時（無論是磁盤、存或是文件）通常需要執(zhí)行兩個步驟：首先測試資源是否空閑可用如果可用，就訪問該資源，否則它等到資源不再使用為止再去訪問它當另一個進程在步驟1和2之間想要訪問同一個資源時將出現(xiàn)問題，導致不可預測的結(jié)果。進程可能會被鎖定，或者一個進程籍此獲得了另一個進程的較大的權(quán)限而導致安全問題。攻擊主要集中在有較大權(quán)限的程序上（稱為setuid程序）。競爭條件攻擊通常利用程序執(zhí)行時可以訪問到的資源。另外權(quán)限低的程序也存在安全風險，因為攻擊者可能會等待有較高權(quán)限的用戶執(zhí)行那個程序(例如root)，然后進行攻擊。

49、下面的建議有助于緩解競爭條件(race condition)攻擊：在進行文件操作時，利用那些使用文件描述符的函數(shù)而不使用那些使用文件路徑的函數(shù)（例如使用fdopen()而不要使用fopen()）。文件描述符使得惡意的用戶在文件打開時或是在原始的進程對文件進行操作前，無法使用文件連接（符號式的或是物理的）來改變文件。在寫文件甚至在讀文件時宜使用fcntl()和flock()函數(shù)來對文件加鎖，這樣它們就不能被其他進程訪問。它幾乎可以建立原子級的操作。應謹慎操縱臨時文件，因為它往往會導致競爭條件攻擊。檢驗有效的返回值檢驗有效的返回值非常重要。一個例子是舊的/bin/login的實現(xiàn)中不檢驗錯誤的返回

50、值，導致當它找不到/etc/passwd文件時返回root的訪問權(quán)限。如果該文件損壞了則這種情況是合理的；但如果該文件存在只是無法訪問，那么這就是一個大問題。系統(tǒng)開發(fā)安全相關工具管理有許多方法來確保代碼符合一定的安全級別。正如前面指出的，最好的方法之一是讓盡可能多的人來檢查代碼（而不是在QA環(huán)境中實際進行白箱或者黑箱測試）。然而，有時代碼在開始實際環(huán)境的應用前往往沒有足夠的時間，并且即使檢查代碼也會漏掉一些不易發(fā)現(xiàn)的錯誤。這些錯誤可能會對整個系統(tǒng)導致重大的安全問題。因此（以與其他的原因），使用源碼分析工具(Source Code Analysis Tool(SCAT)來自動進行某些檢查過程很有

51、幫助。本文介紹了一些這方面的工具。每個工具都用同樣的測試工具來檢驗，這些測試工具包含C和Java的代碼段，而這些代碼段存在潛在的安全錯誤。我們比較了每個工具的測試結(jié)果，并且仔細檢查了以下的屬性：靈活性 有多種選項并能掃描多種類型的代碼的工具得分會較高。正確性 主要目標是發(fā)現(xiàn)正確的安全問題，并且不會出現(xiàn)大量的誤報信息，或者更糟的是沒有發(fā)現(xiàn)真正的錯誤信息。容易使用 大多數(shù)情況下，程序員只需將工具指定到特定的代碼上然后選擇“掃描”。除非特別需要，程序員一般只做抽樣檢查，而無需開發(fā)復雜的測試機制。報表 掃描結(jié)果應以一種容易理解的格式來顯示，并且最好同時提示修改每個問題的方法，并附加理由。每個工具在解析

52、代碼上的速度可以忽略不計，所以沒有進行比較（雖然這并不包括配置掃描的時間，而MOPS在這方面相對于其它工具需要更多的時間）。另外，這些工具都可以免費獲得，甚至可以獲得它們的源代碼，所以不需考慮它們的成本。工具一：PscanPscan是一個有針對性的掃描程序，主要用于發(fā)現(xiàn)C程序中的緩沖區(qū)溢出和格式化字符串攻擊。該程序檢查所有用到標準C程序庫中的printf()函數(shù)。sprintf(buffer, variable); printf(buffer, variable); 關于這些語句在緩沖區(qū)溢出和格式化字符串攻擊中怎樣被利用可以查閱相關的C和C+文檔。Pscan的一個不足是不能發(fā)現(xiàn)由于越界檢查不充

53、分而引起的常規(guī)性緩沖區(qū)溢出。但Pscan對于緩沖區(qū)溢出和格式化字符串攻擊的定位還是相當精準和快速的。Pscan程序相對簡單，它只將結(jié)果返回標準輸出，當然也可以將其輸出到文件，并且除了說明程序員應怎樣修正錯誤以外，不給出語句為什么出錯等類似信息。該工具一個顯著的特點是可以同時掃描多個文件?？傮w而言Pscan程序相對簡單，易于使用，同時針對性很強，但是由于它能夠適用的圍過于狹窄因此一般不推薦其在大型商業(yè)應用中使用，而只是檢查一些相對簡單的程序片斷。工具二：FlawfinderFlawfinder是一個分析C程序安全隱患的靜態(tài)分析工具。和Pscan類似，該程序可以發(fā)現(xiàn)很多種類型的錯誤，除了print

54、f()和標準的字符串函數(shù)，它還可以發(fā)現(xiàn)競爭條件和系統(tǒng)調(diào)用。Flawfinder相比較Pscan，它返回的錯誤信息要豐富很多，并且也更加詳細。而這對于程序員來說非常重要。Flawfinder甚至可以對程序中的弱點進行分類，例如buffer弱點、格式弱點、shell弱點等。 Flawofinder是一個相當出色的C程序檢查工具，速度會，界面友好，返回信息豐富，安裝使用相對簡單。該工具是檢查不同規(guī)模的應用程序的首選，唯一不足的是它只能用于C程序的檢查?？刂栖浖a程序庫管理運作程序庫我們通常將用于系統(tǒng)開發(fā)的軟件工具和開發(fā)平臺稱之為運作程序，因此為了降低計算機程序被破壞的可能性，應對運作程序庫的訪問進

55、行嚴格的控制：嚴格的管理在開發(fā)設備上的存放開發(fā)運作程序的目錄。如果開發(fā)運作程序沒有很好的保護，則系統(tǒng)與其設置可能遭到未經(jīng)授權(quán)的訪問，并造成系統(tǒng)的安全性可靠性大大下降。只有指定的人員如程序庫管理員經(jīng)過適當?shù)墓芾硎跈?quán)后，才可以訪問運作程序庫，對運作程序庫的訪問必須結(jié)合嚴格的訪問控制技術(shù)手段和雙重訪問控制機制。嚴格的訪問控制可以通過以下規(guī)定實現(xiàn)嚴格管理開發(fā)部門所在區(qū)域的保安管理，防止未經(jīng)授權(quán)的人進入開發(fā)區(qū)域。嚴格管理開發(fā)用途的計算機使用，只有指定的人員才可以訪問開發(fā)用的計算機設備。嚴格管理開發(fā)運作系統(tǒng)的認證管理，建立嚴格的基于人員職責的授權(quán)等級制度，用口令或其它身份識別技術(shù)確認訪問者身份。建立雙重訪

56、問控制機制雙重訪問控制機制就是對運作程序庫的管理需經(jīng)兩個人同時進行認證后才可通過的方式。比如對運作程序庫進行更改或刪除需要兩個人進行口令認證，系統(tǒng)才允許進行以上操作。需要進行認證的兩個人彼此不知道對方的認證口令或步驟。因此該認證過程必須兩個人同時在場才可進行操作。管理源程序庫源程序包含了系統(tǒng)與其控制如何實現(xiàn)的細節(jié)，為修改系統(tǒng)提供了很好的切入點，例如設置邏輯炸彈。且如果缺少源程序代碼會使得今后應用系統(tǒng)的維護工作十分困難甚至無法完成。因此為了降低計算機程序被破壞的可能性，應對源程序庫的訪問進行嚴格的控制：嚴格管理在開發(fā)設備上的存放源程序的目錄。如果源程序沒有很好的保護，則系統(tǒng)與其設置可能會遭到未經(jīng)

57、授權(quán)的訪問，并造成系統(tǒng)的安全性可靠性大大下降。只有指定的人員如程序庫管理員經(jīng)過適當?shù)墓芾硎跈?quán)后才可以訪問源程序庫，對源程序庫的訪問必須結(jié)合進行嚴格的訪問控制技術(shù)手段和雙重訪問控制機制。各項應用均應指定相應的管理員。信息技術(shù)支持人員(非開發(fā)人員)不應自由訪問源程序庫。源程序庫和運作程序庫宜分開存放并且分開管理。源程序庫和運行的應用系統(tǒng)宜分開存放且分開管理。源程序庫的更新和向程序員發(fā)布的源程序應由指定的管理員根據(jù)一定的授權(quán)進行，不得私自進行更新或發(fā)放。應保存所有對源程序庫進行訪問讀取或修改的日志記錄，以便日后審核。在軟件開發(fā)過程變更管理a)系統(tǒng)容易受到未經(jīng)授權(quán)的變更的影響，即使是完全授權(quán)的更改也可

58、能存在破壞性的影響，存在數(shù)據(jù)完整性的損失、應用系統(tǒng)的不可用以與信息的泄漏的風險。為了使信息系統(tǒng)的損失降至最小，組織應對更改進行嚴格的控制，即在系統(tǒng)開發(fā)的每一個階段（可行性研究、需求分析、設計、編碼、測試、培訓等）的每一個更改實施前必須經(jīng)過組織的評審與授權(quán)。b)對于敏感的應用系統(tǒng)的更改應由另一人員進行檢查，為了有效的進行控制，組織應建立更改控制審批程序，對更改的申請、評審、測試、批準、更改的計劃的提出和實施提出明確要求并嚴格的實施，確保安全性與控制程序不被損害，程序設計人員應只能訪問他們工作所必需的部分，確保任何的改動都應經(jīng)過審批的。c)更改的程序宜如下：清晰確認所有需要更改的應用系統(tǒng)、信息、數(shù)

59、據(jù)庫和相關的硬件設備。清晰確認更改的原因(業(yè)務上的具體流程和具體的需求或開發(fā)上的需求)。由授權(quán)的用戶提交更改申請。保留相關的授權(quán)登記記錄。在正式實施之前，更改的方案必須經(jīng)過評審并通過正式的批準。確保授權(quán)的用戶在實施之前確認并接受更改的容。確保在實施的過程中，盡量減少對現(xiàn)行的業(yè)務運作系統(tǒng)的影響。確保建立的文件系統(tǒng)在完成各項更改時得到修改，舊文件被很好的歸檔或處置。保證所有的應用系統(tǒng)升級的版本控制。確保對所有的更改請求進行審核跟蹤。確保用戶使用手冊作相應的必要的更改。確保更改的實施選擇了適當?shù)臅r機，以確保更改的實施不會干擾正常的業(yè)務運作。開發(fā)版本管理控制程序清單源程序相關信息可以幫助確認系統(tǒng)問題的

60、根源，并且一旦掌握了系統(tǒng)源程序相關信息可以清楚地了解系統(tǒng)的運行邏輯和可能的薄弱點，對系統(tǒng)的安全有很大的影響。在任何時候?qū)τ诔绦蚯鍐伪仨氝M行嚴格的控制并且與時地進行更新。對應用系統(tǒng)開發(fā)源程序的打印資料、電子版本或者是相關的報告都必須進行控制，紙質(zhì)的文件應保存在一個安全的環(huán)境下，如保險柜等。電子文檔則應進行一定的加密。版本升級控制應用系統(tǒng)軟件開發(fā)版本升級申請。當軟件的版本由于更新、修改等操作需要升級時必須先向相關負責人員提交申請。應用系統(tǒng)軟件版本升級測試。對升級的應用系統(tǒng)進行測試，確認系統(tǒng)的各種安全特性。應用系統(tǒng)軟件版本審批。對應用系統(tǒng)的版本的升級，應確認當前的版本為最新的版本，舊的版本應進行歸檔