【正文】 范、工具使用要求、 代碼集成規(guī)范。2. 針對本規(guī)范提出的主要代碼脆弱性應進行相應的防范設計，具體內容應在軟件概要設計中體現(xiàn)或有單獨的文檔體現(xiàn)。 模塊劃分1. 軟件應該按照安全性劃分模塊，審計和訪問控制模塊為安全可信模塊，其它模塊為不可信任模塊。只有安全可信模塊才可以執(zhí)行安全控制功能，其它的模塊不能訪問安全可信模塊的安全信息、功能或者權限。安全可信模塊應該與其它模塊分離，由經授權的內部專人進行管理。2. 只有安全可信模塊，才能以高安全等級訪問系統(tǒng)的敏感信息，對于其他模塊限制其訪問敏感信息。 最小化功能根據(jù)“沒有明確允許的就默認禁止”的原則， 軟件應只包含那些為達到某個目標而確實需要的功能，不應包含只是在將來某個時間需要但需求說明書中沒有的功能。 軟件在最小化功能建設方面應遵循如下原則：1. 只運行明確定義的功能。2. 系統(tǒng)調用只在確實需要的時候。3. 一次只執(zhí)行一個任務。4. 只有在上一個任務完成后才開始下一個任務。5. 只在確實需要的時候訪問數(shù)據(jù)。 最小化特權1. 只為程序中需要特權的部分授與特權。2. 只授與部分絕對需要的具體特權。3. 將特權的有效時間或者可以有效的時間限制到絕對最小。 對多任務、多進程加以關注軟件開發(fā)應盡量使用單任務的程序。如果軟件需要使用多任務和多進程，應該認真分析研究多任務和多進程會不會發(fā)生沖突，同步所有的進程和任務以避免沖突。 同時作為結構化的編程， 每個原子化組件都要保證一個入口和一個出口。如果進程之間需要交互，則這些交互操作應同步。對于每一種可能的交互情況都要考慮相關的安全策略。 界面輸出最小化軟件應保持用戶界面只提供必須的功能，沒有多余的、不必要的功能，確保用戶不能通過用戶界面直接訪問數(shù)據(jù)或者直接訪問被保護對象。 使代碼簡單、最小化和易于修改開發(fā)時應盡量使代碼簡單、最小化和易于修改。使用結構化的編程語言，盡量避免使用遞歸和 Goto 聲明。使用簡單的代碼，清除不必要的功能，防止采用信息隱藏方式進行數(shù)據(jù)保護。 避免高危的服務、協(xié)議軟件應盡量避免使用不加保護的及已被證明存在安全漏洞的服務和通信協(xié)議傳輸文件，如FTP 、SMTP。 數(shù)據(jù)和代碼分離軟件應該把數(shù)據(jù)與程序放置在不同的目錄中，這里的數(shù)據(jù)包括遠程下載文件等。 關鍵數(shù)據(jù)傳輸保護1. 軟件在傳輸關鍵數(shù)據(jù)時，使用加密算法保證數(shù)據(jù)在通信過程不被破譯，使用數(shù)字簽名保證數(shù)據(jù)在傳輸過程中的一致性和不可否認性。相關的加密算法和簽名技術等應符合國家相關法律法規(guī)要求。2. 信息隱藏是不可靠、 效率低的做法，軟件應該使用正確的安全保護措施，不要依賴隱藏進行數(shù)據(jù)保護。 禁止賦予用戶進程特權用戶進程的授權應采用最小授權法，對于軟件的普通用戶進程，禁止賦予該類進程特權用戶權限。特權用戶類型包括：1. 超級用戶。2. 直接操作數(shù)據(jù)庫用戶。3. 安全管理用戶。 使用適當?shù)臄?shù)據(jù)類型應該小心使用數(shù)據(jù)類型，盡量使用占用內存較小的數(shù)據(jù)類型，如可用整型數(shù)據(jù)的不用實型，特別是在程序接口部分。例如，在一些編程語言中signed 和 unsigned 的數(shù)據(jù)類型是視為不同的（如C或者C++語言）。 使用經過驗證的安全代碼使用經過驗證的安全代碼模塊和外部源程序，防止?jié)撛诘陌踩L險。 使用應用中間件中間件作為一種應用層架構，軟件設計應盡可能使用中間件，中間件選型時應選擇成熟的、業(yè)界主流的中間件產品。 設計錯誤、 異常處理機制軟件設計開發(fā)時應建立防止系統(tǒng)死鎖的機制，異常情況的處理和恢復機制，具體包括錯誤和異常檢測、數(shù)據(jù)回滾、安全錯誤通知、錯誤和異常記錄、斷點保護等。 提供備份機制為保證運行數(shù)據(jù)的完整性和可用性，軟件開發(fā)應設計有效的備份策略，根據(jù)業(yè)務和系統(tǒng)維護需要提供定期或不定期、自動或手動方式的備份機制。 檢查傳遞變量的合法性應檢查所有傳遞給系統(tǒng)函數(shù)調用（System Calls）或本地調用（Native Calls）的變量的合法性。 檢查所有函數(shù)返回代碼應檢查所有函數(shù)調用返回代碼（錯誤代碼），對每個期望的返回值設置相應的處理程序。 修改面向用戶的操作的反饋缺省描述應對面向用戶的操作的反饋缺省描述進行必要的封裝，刪除有關后臺系統(tǒng)或其它敏感信息。 文件操作的要求在需要進行文件操作時，應預先設定目前工作路徑（全路徑名），使用全路徑名表示文件的位置。 其他編碼原則1. 當一個進程對敏感對象（包含秘密信息或包含不可更改信息）使用完后，應立即擦除對象的敏感信息，然后再刪除對象。任何不需要使用的資源應及時釋放。2. 確保所有用來指示數(shù)組下標的數(shù)據(jù)（或指針）都指向了一個有效的數(shù)組元素。 如果某個函數(shù)不能保證下標所指向元素的有效性，或者根本不去檢查邊界時，不要使用該函數(shù)，應該尋找一個安全的函數(shù)，或者自己重新編寫一個或者封裝一個不安全的函數(shù)，加上必要的判斷條件，使它安全。3. 當輸入不可信任數(shù)據(jù)時，要在該數(shù)據(jù)的內容和格式上同時加以檢查。對于整數(shù)，應該檢查數(shù)據(jù)大小是否超出了能夠表示的范圍；對于輸入的字符串，要確保長度沒有溢出，保證每一個字符都是有效的。4. 對經常使用的類似的 SQL 語句應使用綁定變量的方法，避免數(shù)據(jù)庫執(zhí)行類似 SQL 語句時重復解析、重復訪問數(shù)據(jù)文件的行為。5. 程序編碼結束后，應對代碼進行優(yōu)化，提高應用處理 SQL 的性能。6. 禁止使用通配符的方式進行數(shù)據(jù)的插入操作。7. 采用數(shù)據(jù)庫作為系統(tǒng)間接口方式時，應建立獨立的接口表，并按最小化特權原則進行授權。4 應用安全分析 安全需求系統(tǒng)安全本質上屬于信任問題，要保證應用安全，就必須將解決各種操作過程中不可信問題。安全的幾個基本要素為機密性、完整性、可用性、可審計性、不可抵賴性等方面的安全要求。機密性要求保護數(shù)據(jù)內容不能泄露，加密是實現(xiàn)機密性的要求的常見手段。完整性要求保護數(shù)據(jù)內容是完整、沒有被篡改的?？捎眯砸蟊Ｗo資源是可被按照需要訪問。可審計性對出現(xiàn)的安全問題提供調查的依據(jù)和手段。不可抵賴性建立有效的責任機制，防止用戶否認其行為。 安全威脅 Web安全漏洞根據(jù)結合國網(wǎng)系統(tǒng)安全檢測項目常見安全問題及OWASP組織發(fā)布的安全漏洞，系統(tǒng)中存在的需要解決的安全風險如下：序號安全威脅產生環(huán)節(jié)1SQL注入編碼2失效的身份認證及會話管理設計、編碼3跨站腳本（XSS）編碼4點擊劫持（ClickJacking）編碼4不安全的直接對象引用編碼5安全配置錯誤配置實施6敏感信息泄露設計、編碼7功能級訪問控制缺失（失敗的URL訪問權限限制）設計8跨站請求偽造（CSRF）編碼9使用含有已知漏洞的組件管理、設計10未驗證的重定向和轉發(fā)編碼11傳輸層保護不足設計、編碼12文件上傳漏洞編碼13不安全的加密存儲設計、編碼 拒絕服務攻擊分布式拒絕服務攻擊（英文：Distributed Denial of Service，縮寫：DDoS）亦稱洪水攻擊。顧名思義，即是利用網(wǎng)絡上已被攻陷的電腦作為“僵尸”，向某一特定的目標電腦發(fā)動密集式的“拒絕服務”式攻擊，用以把目標電腦的網(wǎng)絡資源及系統(tǒng)資源耗盡，使之無法向真正正常請求的用戶提供服務。黑客通過將一個個“喪尸”或者稱為“肉雞”組成僵尸網(wǎng)絡，就可以發(fā)動大規(guī)模DDoS或SYN洪水網(wǎng)絡攻擊，或者將“喪尸”們組到一起進行帶有利益的刷網(wǎng)站流量、Email垃圾郵件群發(fā)，癱瘓預定目標受雇攻擊競爭對手等商業(yè)活動。 嗅探攻擊利用計算機的網(wǎng)絡接口截獲目的地為其他計算機的數(shù)據(jù)報文的一種技術。它工作在網(wǎng)絡的底層，把網(wǎng)絡傳輸?shù)娜繑?shù)據(jù)記錄下來. 嗅探器可以幫助網(wǎng)絡管理員查找網(wǎng)絡漏洞和檢測網(wǎng)絡性能。嗅探器可以分析網(wǎng)絡的流量，以便找出所關心的網(wǎng)絡中潛在的問題。證明你的網(wǎng)絡有嗅探器有兩條經驗：1. 網(wǎng)絡通訊丟包率非常高：通過一些網(wǎng)管軟件，可以看到信息包傳送情況，最簡單是ping命令。它會告訴你掉了百分之多少的包。如果你的網(wǎng)絡結構正常，而又有20％－30％數(shù)據(jù)包丟失以致數(shù)據(jù)包無法順暢的流到目的地。就有可能有人在監(jiān)聽，這是由于嗅探器攔截數(shù)據(jù)包導致的。2. 網(wǎng)絡帶寬出現(xiàn)反常：通過某些帶寬控制器，可以實時看到目前網(wǎng)絡帶寬的分布情況，如果某臺機器長時間的占用了較大的帶寬，這臺機器就有可能在監(jiān)聽。應該也可以察覺出網(wǎng)絡通訊速度的變化。 中間人攻擊在密碼學和計算機安全領域中，中間人攻擊 （ Maninthemiddle attack，通?？s寫為MITM ）是指攻擊者與通訊的兩端分別建立獨立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內容。在許多情況下這是很簡單的（例如，在一個未加密的WiFi 無線接入點的接受范圍內的中間人攻擊者，可以將自己作為一個中間人插入這個網(wǎng)絡）。 一個中間人攻擊能成功的前提條件是攻擊者能將自己偽裝成每一個參與會話的終端，并且不被其他終端識破。中間人攻擊是一個（缺乏） 相互認證的攻擊。大多數(shù)的加密協(xié)議都專門加入了一些特殊的認證方法以阻止中間人攻擊。例如，SSL協(xié)議可以驗證參與通訊的一方或雙方使用的證書是否是由權威的受信任的數(shù)字證書認證機構頒發(fā)，并且能執(zhí)行雙向身份認證。 安全約束序號限制1外網(wǎng)不允許部署數(shù)據(jù)庫2外網(wǎng)僅提供HTTP、HTTPS訪問，不提供FTP、SFTP等3外網(wǎng)訪問內網(wǎng)必須通過強隔離裝置，僅支持TNS協(xié)議（國網(wǎng)系統(tǒng)要求）4外網(wǎng)應用不允許直接訪問內網(wǎng)關鍵業(yè)務系統(tǒng)數(shù)據(jù)庫5其它系統(tǒng)原則上都不允許直接連接營銷系統(tǒng)數(shù)據(jù)庫5 安全編程要求 輸入處理 建立可信邊界需要在程序中定義清晰的可信邊界。 在一些代碼中用于保存可信數(shù)據(jù)的數(shù)據(jù)結構，不能被用來在其它代碼中存儲不可信數(shù)據(jù)。使數(shù)據(jù)穿越可信邊界的次數(shù)降到最低。當程序混淆了可信和不可信數(shù)據(jù)的界限時會導致安全邊界發(fā)生問題，最容易導致這種錯誤的情況是把可信和不可信數(shù)據(jù)混合在一個數(shù)據(jù)結構里。如下例：該例中程序接受一個 請求并將 usrname 參數(shù)放在 HTTP session 里， 但是并未檢查用戶是否被授權。usrname =(usrname)。if((ATTR_USR)== null){ (ATTR_USR,usrname)。}由于開發(fā)者都知道用戶是不能直接訪問 session 對象的，所以很容易信任來自 session 的所有信息，但是如果在該 session 中混合存儲了可信和不可信的數(shù)據(jù)， 就會違反完全可信邊界的原則，帶來安全隱患。如果不能很好的建立和維護可信邊界，開發(fā)者將不可避免的混淆未被驗證和已驗證的數(shù)據(jù)，從而導致一些數(shù)據(jù)在未經驗證時就被使用。如果輸入的數(shù)據(jù)在處理前通過一些用戶的交互發(fā)生了改變， 可信邊界就會遇到一定的問題，因為它很可能在所有數(shù)據(jù)進入之前不能做出完全的輸入驗證。在這種情況下，維護一個可信的邊界就尤為重要，不可信數(shù)據(jù)應該單獨存放在專門存放不可信數(shù)據(jù)的數(shù)據(jù)結構內，在經過驗證之后才被放在可信區(qū)域。 這樣在看一段代碼時，就很容易識別數(shù)據(jù)是在可信邊界的哪一側。 驗證各種來源的輸入不要將軟件的安全性寄托在配置、使用和維護人員的敏銳理解力、深刻洞察力或良好意愿上，不僅需要驗證用戶輸入，而且還要驗證所有來自于軟件之外的輸入，這些輸入應當包括下列內容，但并不僅僅局限于此：1. HTTP 請求消息的全部字段，包括 GET 數(shù)據(jù)、 POST 數(shù)據(jù)、 COOKIE 和 Header 數(shù)據(jù)等。2. 不可信來源的文件。3. 第三方接口數(shù)據(jù)。4. 從數(shù)據(jù)庫中檢索出的數(shù)據(jù)。5. 對來自命令行、 環(huán)境以及配置文件的輸入。6. 網(wǎng)絡服務。7. 注冊表值。8. 系統(tǒng)性能參數(shù)。9. 臨時文件。 保證所有的輸入信息是被驗證過的確保在輸入驗證之前，新輸入的數(shù)據(jù)不能被添加到程序中（輸入的數(shù)據(jù)不能進入程序代碼中被執(zhí)行）。也就是說，程序默認情況下要對所有的輸入信息進行驗證，不能通過驗證的數(shù)據(jù)將會被拒絕。 對輸入內容進行規(guī)范化處理后再進行驗證當輸入數(shù)據(jù)包含文件名、路徑名、URL 等數(shù)據(jù)時，應先對輸入內容進行規(guī)范化處理后再進行驗證，如文件路徑、URL 地址等數(shù)據(jù)，需要規(guī)范化為標準的格式后再進行驗證。 選擇合適的數(shù)據(jù)驗證方式應根據(jù)情況綜合采用多種輸入驗證的方法，包括：1. 檢查數(shù)據(jù)是否符合期望的類型。2. 檢查數(shù)據(jù)是否符合期望的長度。3. 檢查數(shù)值數(shù)據(jù)是否符合期望的數(shù)值范圍，比如檢測整數(shù)輸入的最大值與最小值。4. 檢查數(shù)據(jù)是否包含特殊字符，如： 、 、 39。、 %、 (、)、 amp。、 +、 \、 \39。、 \等。5. 應使用正則表達式進行白名單檢查盡量避免使用黑名單法。 防范元字符攻擊攻擊者通常會使用元字符對應用程序發(fā)起攻擊。攻擊者可以通過對同一個元字符采取多種編碼方式或者根據(jù)語言特征采取多種實現(xiàn)方式，因此應過濾輸入數(shù)據(jù)中那些具有特定含義的字符，如單引號、雙引號、圓括號、分號等。 拒絕驗證失敗的數(shù)據(jù)應拒絕驗證失敗的輸入數(shù)據(jù)，不試圖對其進行修復（如處理密碼域時自動剪裁掉超過最大長度的輸入，替換掉在輸入框輸入的 JavaScript 字符等）。輸入驗證本身就很復雜，如果和自動錯誤恢復的代碼混合在一起的話，將會造成更大的復雜性，自動錯誤恢復代碼很可能改變請求的含義或者截斷驗證邏輯。如果我們能夠引導用戶，使他們提交的請求能夠通過輸入驗證，就會比專注于自動錯誤恢復代碼有效得多。在驗證失敗時，安全的做法是不試圖修復一個未能通過輸入驗證的請求，直接拒絕掉。 在服務端進行驗證僅在客戶端進行驗證是不安全的，尤其是在 WEB 應用系統(tǒng)中，客戶端的驗證大多采用腳本（如JavaScript）來完成，客戶端的驗證很容易被繞過，安全的做法是在客戶端驗證的同時，在服務器端也進行驗證。 建立統(tǒng)一的輸