應用系統(tǒng)安全開發(fā)技術規(guī)范培訓資料

應用系統(tǒng)安全開發(fā)技術規(guī)范（版本號V1.3）朗新科技股份有限公司二〇一五年十二月更改履歷版本號修改編號更改時間更改的圖表和章節(jié)號更改簡要描述更改人批準人0.52013-11-24初稿施偉施偉1.02015-11-19修改宋月欣陳志明1.12015-11-30修改宋月欣陳志明1.22015-12-3修改宋月欣施偉1.32015-12-3修改施偉注：更改人除形成初稿，以后每次修改在未批準確認前均需采用修訂的方式進行修改。目錄1 背景與目標 12 安全編程概念 12.1 安全編程 12.2 結構化編程 22.3 脆弱性 22.4 可信計算 22.5 安全可信模塊 32.6 不可信任模塊 32.7 敏感信息 32.8 特權 32.9 信息隱藏 32.10 中間件 32.11 死鎖 42.12 可信邊界 42.13 元字符 42.14 參數(shù)化查詢 42.15 UNIXJAIL環(huán)境 42.16 臨時文件 42.17 信息熵 52.18 SSL 52.19 TLS 52.20 HTTPS 52.21 Http會話 52.22 Cookie 62.23 HttpOnlyCookie 63 安全編程原則 63.1 統(tǒng)一的安全規(guī)范 63.2 模塊劃分 63.3 最小化功能 73.4 最小化特權 73.5 對多任務、多進程加以關注 73.6 界面輸出最小化 73.7 使代碼簡單、最小化和易于修改 83.8 避免高危的服務、協(xié)議 83.9 數(shù)據和代碼分離 83.10 關鍵數(shù)據傳輸保護 83.11 禁止賦予用戶進程特權 83.12 使用適當?shù)臄?shù)據類型 93.13 使用經過驗證的安全代碼 93.14 使用應用中間件 93.15 設計錯誤、異常處理機制 93.16 提供備份機制 93.17 檢查傳遞變量的合法性 93.18 檢查所有函數(shù)返回代碼 93.19 修改面向用戶的操作的反饋缺省描述 93.20 文件操作的要求 103.21 其他編碼原則 104 應用安全分析 114.1 安全需求 114.2 安全威脅 114.2.1 Web安全漏洞 114.2.2 拒絕服務攻擊 124.2.3 嗅探攻擊 124.2.4 中間人攻擊 124.3 安全約束 135 安全編程要求 135.1 輸入處理 135.1.1 建立可信邊界 135.1.2 驗證各種來源的輸入 145.1.3 保證所有的輸入信息是被驗證過的 145.1.4 對輸入內容進行規(guī)范化處理后再進行驗證 155.1.5 選擇合適的數(shù)據驗證方式 155.1.6 防范元字符攻擊 155.1.7 拒絕驗證失敗的數(shù)據 155.1.8 在服務端進行驗證 155.1.9 建立統(tǒng)一的輸入驗證接口 165.1.10 控制寫入日志的信息 165.1.11 從服務器端提取關鍵參數(shù) 165.2 輸出處理 165.2.1 限制返回給客戶的信息 165.2.2 建立錯誤信息保護機制 165.3 數(shù)據庫訪問 165.3.1 合理分配數(shù)據庫訪問權限 165.3.2 合理存放數(shù)據庫連接帳號和密碼信息 175.3.3 使用參數(shù)化請求方式 175.3.4 對SQL語句中來自于不可信區(qū)域的輸入參數(shù)進行驗證 185.3.5 對數(shù)據庫操作的返回數(shù)據進行驗證 185.3.6 分次提取數(shù)據 185.3.7 通過row（行）級別的訪問控制來使用數(shù)據庫 185.3.8 確保數(shù)據庫資源被釋放 185.4 文件操作 195.4.1 對上傳文件進行限制 195.4.2 把文件名以及文件內容作為不可信的輸入對待 195.4.3 安全的使用文件名 195.4.4 使用文件系統(tǒng)訪問控制 195.4.5 注意文件訪問競爭條件 195.4.6 安全使用臨時文件 205.4.7 確保文件系統(tǒng)資源被釋放 206 安全特征 206.1 關注應用的對象重用 206.2 用戶訪問控制信息的機密性 206.3 不要在客戶端存放敏感數(shù)據 206.4 避免內存溢出 216.5 可配置數(shù)據保護 216.6 禁止在源代碼中寫入口令 216.7 隨機數(shù) 216.8 使用可信的密碼算法 226.9 異常管理 227 應用安全設計規(guī)范 237.1 應用安全規(guī)劃 237.2 數(shù)據安全等級劃分 237.3 數(shù)據庫規(guī)劃 237.3.1 用戶權限 237.3.2 數(shù)據源設計 237.3.3 外部系統(tǒng)訪問 237.4 角色劃分 247.5 URL規(guī)劃 247.6 程序文件目錄規(guī)劃 247.6.1 數(shù)據及程序分離 247.6.2 靜態(tài)程序資源 247.6.3 程序文件分類 247.7 Cookie 247.8 文件安全 257.8.1 文件存儲 257.8.2 文件操作 257.8.3 文件類型 257.9 第三方組件安全 257.9.1 組件兼容性 257.9.2 組件安全及成熟度 257.9.3 組件配置 257.10 WebService 257.11 RESTfulWebService 267.12 應用安全關注點 277.13 應用安全限制應對方案 297.13.1 外網隔離 297.13.2 外網文件操作 297.13.3 正向和反向隔離裝置（國網系統(tǒng)） 298 應用安全開發(fā)規(guī)范 308.1 Java及Web安全編程規(guī)范 308.1.1 不信任未知 308.1.2 數(shù)據層開發(fā) 308.1.3 會話管理 328.1.4 Cookie 338.1.5 輸入驗證 338.1.6 輸入文件名的驗證 348.1.7 輸出處理 348.1.8 敏感信息處理 368.1.9 異常信息處理 378.1.10 特殊頁面跳轉 378.1.11 文件操作 378.1.12 資源釋放 388.1.13 內存控制 388.1.14 外部程序調用漏洞 388.1.15 整數(shù)溢出 398.2 C++安全編程規(guī)范 398.2.1 不信任未知 398.2.2 免緩存區(qū)溢出 408.2.3 免緩整數(shù)溢出 428.2.4 域名合法性檢查 458.2.5 檢查返回值 468.2.6 產生隨機數(shù) 478.2.7 驗證輸入文件名 488.2.8 類設計注意事項 488.2.9 外部程序調用漏洞 508.2.10 臨時文件處理 50背景與目標在Internet大眾化及Web技術飛速演變的今天，Web安全所面臨的挑戰(zhàn)日益嚴峻。黑客攻擊技術越來越成熟和大眾化，針對Web的攻擊和破壞不斷增長，Web安全風險達到了前所未有的高度。許多程序員不知道如何開發(fā)安全的應用程序，開發(fā)出來的Web應用存在較多的安全漏洞，這些安全漏洞一旦被黑客利用將導致嚴重甚至是災難性的后果。這并非危言聳聽，類似的網上事故舉不勝舉，公司的Web產品也曾多次遭黑客攻擊，甚至有黑客利用公司Web產品的漏洞敲詐運營商，造成極其惡劣的影響。本規(guī)范為解決Web應用系統(tǒng)安全問題，對主要的應用安全問題進行分析，并有針對性的從設計及開發(fā)規(guī)范、開發(fā)管理、安全組件框架、安全測試方面提供整體的安全解決方案。使本組織能以標準的、規(guī)范的方式設計和編碼。通過建立編碼規(guī)范，以使每個開發(fā)人員養(yǎng)成良好的編碼風格和習慣；并以此形成開發(fā)小組編碼約定，提高程序的可靠性、可讀性、可修改性、可維護性和一致性等，增進團隊間的交流，并保證軟件產品的質量。安全編程概念安全編程安全編程是指開發(fā)人員首先需要具備一定的安全知識，然后識別數(shù)據在流轉（輸入、處理和輸出）過程中可能面對的威脅，對這些威脅進行分析得出其利用的漏洞，通過合理地編寫代碼消除這些漏洞，降低軟件面臨的風險。本規(guī)范對開發(fā)人員的編碼提出統(tǒng)一的安全要求，主要涉及輸入處理、輸出處理、數(shù)據庫訪問、文件操作、異常管理等方面，如下圖：輸入處理部分能指導開發(fā)者避免用戶的不良輸入；輸出處理能指導開發(fā)者對輸出內容進行過濾；數(shù)據庫訪問、文件操作部分則能指導開發(fā)者進行數(shù)據庫查詢，寫入文件等操作時進行防護；而異常管理、敏感數(shù)據保護、對象重用等技術則指導開發(fā)者改進軟件的自身缺陷。WEB開發(fā)規(guī)范部分則指導用戶在WEB系統(tǒng)（B/S架構應用）的研發(fā)方面時如何增加對應用軟件的保護。結構化編程結構化編程，一種編程典范。它采用子程序、程式碼區(qū)塊、for循環(huán)以及while循環(huán)等結構，來取代傳統(tǒng)的goto。希望借此來改善計算機程序的明晰性、品質以及開發(fā)時間，并且避免寫出面條式代碼。脆弱性脆弱性指計算機系統(tǒng)安全方面的缺陷，使得系統(tǒng)或其應用數(shù)據的保密性、完整性、可用性、訪問控制、監(jiān)測機制等面臨威脅?？尚庞嬎憧尚庞嬎愕男袨闀娴刈裱O計，而執(zhí)行設計者和軟件編寫者所禁止的行為的概率很低。安全可信模塊審計和訪問控制模塊是唯一的安全可信模塊。不可信任模塊除審計和訪問控制模塊外其它所有模塊均為不可信模塊。敏感信息系統(tǒng)的敏感信息包括用戶身份信息、認證信息、授權信息、交易過程中的私密或隱私信息、其它的敏感信息。特權特權只是允許去做并不是每個人都可以做的事情。信息隱藏信息隱藏指在設計和確定模塊時，使得一個模塊內包含的特定信息（過程或數(shù)據），對于不需要這些信息的其他模塊來說，是不可訪問的。信息隱藏基本原理框圖：中間件中間件是提供系統(tǒng)軟件和應用軟件之間連接的軟件，以便于軟件各部件之間的溝通.中間件技術創(chuàng)建在對應用軟件部分常用功能的抽象上，將常用且重要的過程調用、分布式組件、消息隊列、事務、安全、連結器、商業(yè)流程、網絡并發(fā)、HTTP服務器、WebService等功能集于一身或者分別在不同品牌的不同產品中分別完成。死鎖死鎖是操作系統(tǒng)或軟件運行的一種狀態(tài)：在多任務系統(tǒng)下，當一個或多個進程等待系統(tǒng)資源，而資源又被進程本身或其它進程占用時，就形成了死鎖?？尚胚吔缈尚胚吔缈梢员徽J為是在程序中劃定的一條分隔線，一邊的數(shù)據是不可信的而另一邊則是可信的。當數(shù)據要從不可信的一側到可信一側的時候，需要使用驗證邏輯進行判斷。元字符元字符就是在編程語言中具有特定含義的字符或者字符串。例如在SQL查詢中，單引號（‘）是危險的字符；在文件系統(tǒng)路徑中兩個點號（..）是危險的字符；在命令shell中，分號（；）和雙&（&&）符號同樣是危險的字符，而換行符（\n）對日志文件很關鍵。參數(shù)化查詢參數(shù)化查詢（ParameterizedQuery或ParameterizedStatement）是指在設計與數(shù)據庫鏈接并訪問數(shù)據時，在需要填入數(shù)值或數(shù)據的地方，使用參數(shù)(Parameter)來給值，這個方法目前已被視為最有效可預防SQL注入攻擊(SQLInjection)的攻擊手法的防御方式。UNIXJAIL環(huán)境一個被改變根目錄的程序不可以訪問和命名在被改變根目錄外的文件，那個根目錄叫做“chroot監(jiān)獄（chrootjail,chrootprison)”。臨時文件創(chuàng)建臨時文件的程序會在完成時將其刪除。信息熵信息熵指信息的不確定性,一則高信息度的信息熵是很低的,低信息度的熵則高。SSL安全套接層（SecureSocketsLayer，SSL），一種安全協(xié)議，是網景公司（Netscape）在推出Web瀏覽器首版的同時提出的，目的是為網絡通信提供安全及數(shù)據完整性。SSL在傳輸層對網絡連接進行加密。SSL采用公開密鑰技術，保證兩個應用間通信的保密性和可靠性，使客戶與服務器應用之間的通信不被攻擊者竊聽。它在服務器和客戶機兩端可同時被支持，目前已成為互聯(lián)網上保密通訊的工業(yè)標準?，F(xiàn)行Web瀏覽器亦普遍將HTTP和SSL相結合，從而實現(xiàn)安全通信。此協(xié)議和其繼任者是TLS。TLSSSL（SecureSocketsLayer）是網景公司（Netscape）設計的主要用于Web的安全傳輸協(xié)議。這種協(xié)議在Web上獲得了廣泛的應用。IETF（）將SSL作了標準化，即RFC2246，并將其稱為TLS（TransportLayerSecurity），其最新版本是RFC5246,版本1.2。從技術上講，TLS1.0與SSL3.0的差異非常微小。HTTPS超文本傳輸安全協(xié)議（縮寫：HTTPS，英語：HypertextTransferProtocolSecure）是超文本傳輸協(xié)議和SSL/TLS的組合，用以提供加密通訊及對網絡服務器身份的鑒定。HTTPS連接經常被用于萬維網上的交易支付和企業(yè)信息系統(tǒng)中敏感信息的傳輸。HTTPS不應與在RFC2660中定義的安全超文本傳輸協(xié)議（S-HTTP）相混。Http會話在計算機科學領域來說，尤其是在網絡領域，會話（session）是一種持久網絡協(xié)議，在用戶（或用戶代理）端和服務器端之間創(chuàng)建關聯(lián)，從而起到交換數(shù)據包的作用機制，session在網絡協(xié)議（例如telnet或FTP）中是非常重要的部分。在不包含會話層（例如UDP）或者是無法長時間駐留會話層（例如HTTP）的傳輸協(xié)議中，會話的維持需要依靠在傳輸數(shù)據中的高級別程序。例如，在瀏覽器和遠程主機之間的HTTP傳輸中，HTTPcookie就會被用來包含一些相關的信息，例如sessionID，參數(shù)和權限信息等。當客戶端在多個服務器調取數(shù)據時，保持會話狀態(tài)的一致性是需要注意的，客戶端需用同時保持和某一個主機的連接，或者多個服務器端需要共享一個儲存會話信息的文件系統(tǒng)或者數(shù)據庫。否則，當用戶在一個新的而不是一開始保存會話信息的主機上提交訪問請求的時候，主機會因為無法獲知原來主機的會話的訪問狀態(tài)而產生問題。CookieCookie（復數(shù)形態(tài)Cookies），中文名稱為小型文本文件或小甜餅，指某些網站為了辨別用戶身份而儲存在用戶本地終端（ClientSide）上的數(shù)據（通常經過加密）。定義于RFC2109。為網景公司的前雇員LouMontulli在1993年3月所發(fā)明。HttpOnlyCookieHttpOnly是包含在Http響應頭信息Set-Cookie中的一個額外標志，如果瀏覽器支持HttpOnly標志的話，在生成Cookie時使用HttpOnly標志可幫助減輕客戶端腳本訪問受保護的Cookie時帶來的風險（客戶端腳本不能訪問HttpOnlyCookie）。安全編程原則統(tǒng)一的安全規(guī)范每個軟件項目在設計階段都應明確在項目實施過程中項目組應遵循的統(tǒng)一規(guī)范，具體包括：命名規(guī)則、組件使用規(guī)范、異常處理規(guī)范、日志處理規(guī)范、工具使用要求、代碼集成規(guī)范。針對本規(guī)范提出的主要代碼脆弱性應進行相應的防范設計，具體內容應在軟件概要設計中體現(xiàn)或有單獨的文檔體現(xiàn)。模塊劃分軟件應該按照安全性劃分模塊，審計和訪問控制模塊為安全可信模塊，其它模塊為不可信任模塊。只有安全可信模塊才可以執(zhí)行安全控制功能，其它的模塊不能訪問安全可信模塊的安全信息、功能或者權限。安全可信模塊應該與其它模塊分離，由經授權的內部專人進行管理。只有安全可信模塊，才能以高安全等級訪問系統(tǒng)的敏感信息，對于其他模塊限制其訪問敏感信息。最小化功能根據“沒有明確允許的就默認禁止”的原則，軟件應只包含那些為達到某個目標而確實需要的功能，不應包含只是在將來某個時間需要但需求說明書中沒有的功能。軟件在最小化功能建設方面應遵循如下原則：只運行明確定義的功能。系統(tǒng)調用只在確實需要的時候。一次只執(zhí)行一個任務。只有在上一個任務完成后才開始下一個任務。只在確實需要的時候訪問數(shù)據。最小化特權只為程序中需要特權的部分授與特權。只授與部分絕對需要的具體特權。將特權的有效時間或者可以有效的時間限制到絕對最小。對多任務、多進程加以關注軟件開發(fā)應盡量使用單任務的程序。如果軟件需要使用多任務和多進程，應該認真分析研究多任務和多進程會不會發(fā)生沖突，同步所有的進程和任務以避免沖突。同時作為結構化的編程，每個原子化組件都要保證一個入口和一個出口。如果進程之間需要交互，則這些交互操作應同步。對于每一種可能的交互情況都要考慮相關的安全策略。界面輸出最小化軟件應保持用戶界面只提供必須的功能，沒有多余的、不必要的功能，確保用戶不能通過用戶界面直接訪問數(shù)據或者直接訪問被保護對象。使代碼簡單、最小化和易于修改開發(fā)時應盡量使代碼簡單、最小化和易于修改。使用結構化的編程語言，盡量避免使用遞歸和Goto聲明。使用簡單的代碼，清除不必要的功能，防止采用信息隱藏方式進行數(shù)據保護。避免高危的服務、協(xié)議軟件應盡量避免使用不加保護的及已被證明存在安全漏洞的服務和通信協(xié)議傳輸文件，如FTP、SMTP。數(shù)據和代碼分離軟件應該把數(shù)據與程序放置在不同的目錄中，這里的數(shù)據包括遠程下載文件等。關鍵數(shù)據傳輸保護軟件在傳輸關鍵數(shù)據時，使用加密算法保證數(shù)據在通信過程不被破譯，使用數(shù)字簽名保證數(shù)據在傳輸過程中的一致性和不可否認性。相關的加密算法和簽名技術等應符合國家相關法律法規(guī)要求。信息隱藏是不可靠、效率低的做法，軟件應該使用正確的安全保護措施，不要依賴隱藏進行數(shù)據保護。禁止賦予用戶進程特權用戶進程的授權應采用最小授權法，對于軟件的普通用戶進程，禁止賦予該類進程特權用戶權限。特權用戶類型包括：超級用戶。直接操作數(shù)據庫用戶。安全管理用戶。使用適當?shù)臄?shù)據類型應該小心使用數(shù)據類型，盡量使用占用內存較小的數(shù)據類型，如可用整型數(shù)據的不用實型，特別是在程序接口部分。例如，在一些編程語言中signed和unsigned的數(shù)據類型是視為不同的（如C或者C++語言）。使用經過驗證的安全代碼使用經過驗證的安全代碼模塊和外部源程序，防止?jié)撛诘陌踩L險。使用應用中間件中間件作為一種應用層架構，軟件設計應盡可能使用中間件，中間件選型時應選擇成熟的、業(yè)界主流的中間件產品。設計錯誤、異常處理機制軟件設計開發(fā)時應建立防止系統(tǒng)死鎖的機制，異常情況的處理和恢復機制，具體包括錯誤和異常檢測、數(shù)據回滾、安全錯誤通知、錯誤和異常記錄、斷點保護等。提供備份機制為保證運行數(shù)據的完整性和可用性，軟件開發(fā)應設計有效的備份策略，根據業(yè)務和系統(tǒng)維護需要提供定期或不定期、自動或手動方式的備份機制。檢查傳遞變量的合法性應檢查所有傳遞給系統(tǒng)函數(shù)調用（SystemCalls）或本地調用（NativeCalls）的變量的合法性。檢查所有函數(shù)返回代碼應檢查所有函數(shù)調用返回代碼（錯誤代碼），對每個期望的返回值設置相應的處理程序。修改面向用戶的操作的反饋缺省描述應對面向用戶的操作的反饋缺省描述進行必要的封裝，刪除有關后臺系統(tǒng)或其它敏感信息。文件操作的要求在需要進行文件操作時，應預先設定目前工作路徑（全路徑名），使用全路徑名表示文件的位置。其他編碼原則當一個進程對敏感對象（包含秘密信息或包含不可更改信息）使用完后，應立即擦除對象的敏感信息，然后再刪除對象。任何不需要使用的資源應及時釋放。確保所有用來指示數(shù)組下標的數(shù)據（或指針）都指向了一個有效的數(shù)組元素。如果某個函數(shù)不能保證下標所指向元素的有效性，或者根本不去檢查邊界時，不要使用該函數(shù)，應該尋找一個安全的函數(shù)，或者自己重新編寫一個或者封裝一個不安全的函數(shù)，加上必要的判斷條件，使它安全。當輸入不可信任數(shù)據時，要在該數(shù)據的內容和格式上同時加以檢查。對于整數(shù)，應該檢查數(shù)據大小是否超出了能夠表示的范圍；對于輸入的字符串，要確保長度沒有溢出，保證每一個字符都是有效的。對經常使用的類似的SQL語句應使用綁定變量的方法，避免數(shù)據庫執(zhí)行類似SQL語句時重復解析、重復訪問數(shù)據文件的行為。程序編碼結束后，應對代碼進行優(yōu)化，提高應用處理SQL的性能。禁止使用通配符的方式進行數(shù)據的插入操作。采用數(shù)據庫作為系統(tǒng)間接口方式時，應建立獨立的接口表，并按最小化特權原則進行授權。應用安全分析安全需求系統(tǒng)安全本質上屬于信任問題，要保證應用安全，就必須將解決各種操作過程中不可信問題。安全的幾個基本要素為機密性、完整性、可用性、可審計性、不可抵賴性等方面的安全要求。機密性要求保護數(shù)據內容不能泄露，加密是實現(xiàn)機密性的要求的常見手段。完整性要求保護數(shù)據內容是完整、沒有被篡改的?？捎眯砸蟊Ｗo資源是可被按照需要訪問?？蓪徲嬓詫Τ霈F(xiàn)的安全問題提供調查的依據和手段。不可抵賴性建立有效的責任機制，防止用戶否認其行為。安全威脅Web安全漏洞根據結合國網系統(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不安全的加密存儲設計、編碼拒絕服務攻擊分布式拒絕服務攻擊（英文：DistributedDenialofService，縮寫：DDoS）亦稱洪水攻擊。顧名思義，即是利用網絡上已被攻陷的電腦作為“僵尸”，向某一特定的目標電腦發(fā)動密集式的“拒絕服務”式攻擊，用以把目標電腦的網絡資源及系統(tǒng)資源耗盡，使之無法向真正正常請求的用戶提供服務。黑客通過將一個個“喪尸”或者稱為“肉雞”組成僵尸網絡，就可以發(fā)動大規(guī)模DDoS或SYN洪水網絡攻擊，或者將“喪尸”們組到一起進行帶有利益的刷網站流量、Email垃圾郵件群發(fā)，癱瘓預定目標受雇攻擊競爭對手等商業(yè)活動。嗅探攻擊利用計算機的網絡接口截獲目的地為其他計算機的數(shù)據報文的一種技術。它工作在網絡的底層，把網絡傳輸?shù)娜繑?shù)據記錄下來.嗅探器可以幫助網絡管理員查找網絡漏洞和檢測網絡性能。嗅探器可以分析網絡的流量，以便找出所關心的網絡中潛在的問題。證明你的網絡有嗅探器有兩條經驗：網絡通訊丟包率非常高：通過一些網管軟件，可以看到信息包傳送情況，最簡單是ping命令。它會告訴你掉了百分之多少的包。如果你的網絡結構正常，而又有20％－30％數(shù)據包丟失以致數(shù)據包無法順暢的流到目的地。就有可能有人在監(jiān)聽，這是由于嗅探器攔截數(shù)據包導致的。網絡帶寬出現(xiàn)反常：通過某些帶寬控制器，可以實時看到目前網絡帶寬的分布情況，如果某臺機器長時間的占用了較大的帶寬，這臺機器就有可能在監(jiān)聽。應該也可以察覺出網絡通訊速度的變化。中間人攻擊在密碼學和計算機安全領域中，中間人攻擊（Man-in-the-middleattack，通?？s寫為MITM）是指攻擊者與通訊的兩端分別建立獨立的聯(lián)系，并交換其所收到的數(shù)據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內容。在許多情況下這是很簡單的（例如，在一個未加密的Wi-Fi無線接入點的接受范圍內的中間人攻擊者，可以將自己作為一個中間人插入這個網絡）。一個中間人攻擊能成功的前提條件是攻擊者能將自己偽裝成每一個參與會話的終端，并且不被其他終端識破。中間人攻擊是一個（缺乏）相互認證的攻擊。大多數(shù)的加密協(xié)議都專門加入了一些特殊的認證方法以阻止中間人攻擊。例如，SSL協(xié)議可以驗證參與通訊的一方或雙方使用的證書是否是由權威的受信任的數(shù)字證書認證機構頒發(fā)，并且能執(zhí)行雙向身份認證。安全約束序號限制1外網不允許部署數(shù)據庫2外網僅提供HTTP、HTTPS訪問，不提供等3外網訪問內網必須通過強隔離裝置，僅支持TNS協(xié)議（國網系統(tǒng)要求）4外網應用不允許直接訪問內網關鍵業(yè)務系統(tǒng)數(shù)據庫5其它系統(tǒng)原則上都不允許直接連接營銷系統(tǒng)數(shù)據庫安全編程要求輸入處理建立可信邊界需要在程序中定義清晰的可信邊界。在一些代碼中用于保存可信數(shù)據的數(shù)據結構，不能被用來在其它代碼中存儲不可信數(shù)據。使數(shù)據穿越可信邊界的次數(shù)降到最低。當程序混淆了可信和不可信數(shù)據的界限時會導致安全邊界發(fā)生問題，最容易導致這種錯誤的情況是把可信和不可信數(shù)據混合在一個數(shù)據結構里。如下例：該例中程序接受一個http請求并將"usrname"參數(shù)放在HTTPsession里，但是并未檢查用戶是否被授權。usrname=request.getParameter("usrname");usrname=request.getParameter("usrname");if(session.getAttribute(ATTR_USR)==null){ session.setAttribute(ATTR_USR,usrname);}由于開發(fā)者都知道用戶是不能直接訪問session對象的，所以很容易信任來自session的所有信息，但是如果在該session中混合存儲了可信和不可信的數(shù)據，就會違反完全可信邊界的原則，帶來安全隱患。如果不能很好的建立和維護可信邊界，開發(fā)者將不可避免的混淆未被驗證和已驗證的數(shù)據，從而導致一些數(shù)據在未經驗證時就被使用。如果輸入的數(shù)據在處理前通過一些用戶的交互發(fā)生了改變，可信邊界就會遇到一定的問題，因為它很可能在所有數(shù)據進入之前不能做出完全的輸入驗證。在這種情況下，維護一個可信的邊界就尤為重要，不可信數(shù)據應該單獨存放在專門存放不可信數(shù)據的數(shù)據結構內，在經過驗證之后才被放在可信區(qū)域。這樣在看一段代碼時，就很容易識別數(shù)據是在可信邊界的哪一側。驗證各種來源的輸入不要將軟件的安全性寄托在配置、使用和維護人員的敏銳理解力、深刻洞察力或良好意愿上，不僅需要驗證用戶輸入，而且還要驗證所有來自于軟件之外的輸入，這些輸入應當包括下列內容，但并不僅僅局限于此：HTTP請求消息的全部字段，包括GET數(shù)據、POST數(shù)據、COOKIE和Header數(shù)據等。不可信來源的文件。第三方接口數(shù)據。從數(shù)據庫中檢索出的數(shù)據。對來自命令行、環(huán)境以及配置文件的輸入。網絡服務。注冊表值。系統(tǒng)性能參數(shù)。臨時文件。保證所有的輸入信息是被驗證過的確保在輸入驗證之前，新輸入的數(shù)據不能被添加到程序中（輸入的數(shù)據不能進入程序代碼中被執(zhí)行）。也就是說，程序默認情況下要對所有的輸入信息進行驗證，不能通過驗證的數(shù)據將會被拒絕。對輸入內容進行規(guī)范化處理后再進行驗證當輸入數(shù)據包含文件名、路徑名、URL等數(shù)據時，應先對輸入內容進行規(guī)范化處理后再進行驗證，如文件路徑、URL地址等數(shù)據，需要規(guī)范化為標準的格式后再進行驗證。選擇合適的數(shù)據驗證方式應根據情況綜合采用多種輸入驗證的方法，包括：檢查數(shù)據是否符合期望的類型。檢查數(shù)據是否符合期望的長度。檢查數(shù)值數(shù)據是否符合期望的數(shù)值范圍，比如檢測整數(shù)輸入的最大值與最小值。檢查數(shù)據是否包含特殊字符，如：、"、'、%、(、)、&、+、\、\'、\"等。應使用正則表達式進行白名單檢查盡量避免使用黑名單法。防范元字符攻擊攻擊者通常會使用元字符對應用程序發(fā)起攻擊。攻擊者可以通過對同一個元字符采取多種編碼方式或者根據語言特征采取多種實現(xiàn)方式，因此應過濾輸入數(shù)據中那些具有特定含義的字符，如單引號、雙引號、圓括號、分號等。拒絕驗證失敗的數(shù)據應拒絕驗證失敗的輸入數(shù)據，不試圖對其進行修復（如處理密碼域時自動剪裁掉超過最大長度的輸入，替換掉在輸入框輸入的JavaScript字符等）。輸入驗證本身就很復雜，如果和自動錯誤恢復的代碼混合在一起的話，將會造成更大的復雜性，自動錯誤恢復代碼很可能改變請求的含義或者截斷驗證邏輯。如果我們能夠引導用戶，使他們提交的請求能夠通過輸入驗證，就會比專注于自動錯誤恢復代碼有效得多。在驗證失敗時，安全的做法是不試圖修復一個未能通過輸入驗證的請求，直接拒絕掉。在服務端進行驗證僅在客戶端進行驗證是不安全的，尤其是在WEB應用系統(tǒng)中，客戶端的驗證大多采用腳本（如JavaScript）來完成，客戶端的驗證很容易被繞過，安全的做法是在客戶端驗證的同時，在服務器端也進行驗證。建立統(tǒng)一的輸入驗證接口應建立統(tǒng)一的輸入驗證接口，為整個應用系統(tǒng)提供一致的驗證方法，這樣可以避免分散驗證帶來的代碼管理混亂，并且可以減少遺漏。控制寫入日志的信息由于日志數(shù)據的價值，它也成為了攻擊者的目標。如果攻擊者可以控制寫進日志文件的信息，他們就可以在輸入中混入偽造的日志條目來偽造系統(tǒng)事件，更嚴重的是，如果負責進行日志分析的代碼存在漏洞，特定的有惡意的輸入數(shù)據很可能觸發(fā)該漏洞，并引發(fā)更加嚴重的危害。如果日志數(shù)據中包含輸入數(shù)據，應對輸入數(shù)據進行驗證，禁止攻擊者能夠寫任意的數(shù)據到日志中。從服務器端提取關鍵參數(shù)需要獲取參數(shù)時，應當從服務器端提取關鍵參數(shù)，禁止從客戶端輸入，例如產品價格、用戶角色、鑒權標志等，如果關鍵參數(shù)允許從客戶端輸入提供，攻擊者可通過偽造或篡改輸入數(shù)據造成程序關鍵邏輯錯誤。輸出處理限制返回給客戶的信息編碼時應該限制返回給客戶與業(yè)務處理無關的信息，禁止把重點保護數(shù)據返回給不信任的用戶，避免信息外泄。建立錯誤信息保護機制開發(fā)人員在編碼時，禁止將詳細錯誤信息直接反饋到客戶端，詳細錯誤信息中包含系統(tǒng)信息、文件和目錄的絕對路徑信息，應對錯誤信息進行規(guī)整和清理后再返回到客戶端，建議只向客戶端返回錯誤碼，詳細錯誤信息可以記錄在后臺服務器。數(shù)據庫訪問合理分配數(shù)據庫訪問權限應按照“最小化原則”為應用程序分配數(shù)據庫訪問權限。避免為應用程序分配過大或不必要的數(shù)據庫權限，禁止將數(shù)據庫DBA權限分配給應用程序。合理存放數(shù)據庫連接帳號和密碼信息禁止在應用程序代碼和配置文件明文存放數(shù)據庫連接帳號和密碼信息，建議對數(shù)據庫連接賬戶和密碼信息加密后再保存在配置文件中。使用參數(shù)化請求方式使用參數(shù)化的SQL請求是防止SQL注入的有效方法。導致SQL注入漏洞的原因就是攻擊者可以改變SQL請求的內容，攻擊者提交的數(shù)據變成了SQL執(zhí)行命令的一部分。在構造SQL請求時，開發(fā)者應當知道哪些應該被翻譯為數(shù)據而哪些應該被翻譯為命令的一部分。如果正確的使用參數(shù)化的SQL語句，就可以通過不允許數(shù)據指向改變的方法來防御幾乎所有的SQL注入攻擊。參數(shù)化的SQL語句通常是由SQL字符構造的，但是來自客戶的數(shù)據是需要與一些綁定參數(shù)組合在一起的。也就是說，開發(fā)者使用這些綁定參數(shù)來準確的向數(shù)據庫指出哪些應該被當作數(shù)據，哪些應該被當作命令。當程序要執(zhí)行該語句的時候，它就會告知數(shù)據庫這些綁定參數(shù)的運行值，這樣就避免了數(shù)據被認為是命令語句而被執(zhí)行的錯誤。但是，如下是SQL請求中包含字符串拼接造成SQL注入漏洞的例子：這是一個javaweb應用程序，讓用戶在數(shù)據庫中搜索一些信息，用戶可以指定要搜尋的對象名稱，并用以下代碼執(zhí)行這些查詢：Stringitem=request.getParamater("item");Stringq="SELECT*FROMrecordsWHEREitem="+item;PreparedStatementstmt=conn.prepareStatement(q);ResultSetresults=stmt.execute();...雖然本例程序使用了參數(shù)化的接口，但是它犯了一個很常見的錯誤：把用戶的輸入作為prepareStatement()的參數(shù)傳入，如果允許用戶控制PreparedStatement的內容，參數(shù)化SQL提供的安全特性就會失去效果，很多SQL注入攻擊的關鍵字也會被包含在之前構造的語句中。合理的使用參數(shù)化SQL代碼如下：Stringitem=request.getParamater("item");Stringq="SELECT*FROMrecordsWHEREitem=?";PreparedStatementstmt=conn.prepareStatement(q);stmt.setString(1,item);ResultSetresults=stmt.execute();...對SQL語句中來自于不可信區(qū)域的輸入參數(shù)進行驗證在一些復雜的情況會出現(xiàn)要求輸入影響SQL語句結構的情況，譬如要求在where子句里增加一個動態(tài)約束，這時應對來自不可信區(qū)域的輸入參數(shù)進行驗證。對數(shù)據庫操作的返回數(shù)據進行驗證不應盲目信任來自數(shù)據庫的數(shù)據，建議對來自數(shù)據庫的數(shù)據進行驗證，確保其格式正確且能夠安全的使用：檢查SQL請求的返回記錄數(shù)，SQL請求的預期結果為單值數(shù)據，但存在多行結果時，表明SQL請求中被可能被攻擊者插入了注入語句，此時應中止后續(xù)處理并記錄日志。將來自數(shù)據庫的數(shù)據做為輸入數(shù)據時，也應進行驗證。分次提取數(shù)據對于數(shù)據庫查詢操作，如果查詢返回的結果較多時，應設計成分次提取，應避免一次提取過多數(shù)據。通過row（行）級別的訪問控制來使用數(shù)據庫不要依賴應用程序訪問控制能夠保護數(shù)據庫的數(shù)據，限制每個請求使用戶只能訪問他們自己的數(shù)據。通過row級別的訪問控制是防止用戶信息泄露的“最后的防線”了。限制SQL請求只向當前認證的用戶返回結果。當用戶要執(zhí)行SQL語句時，根據用戶提交的用戶名或者ID進行判斷是否具有執(zhí)行該SQL語句操作的權限，來限制攻擊者越權來執(zhí)行SQL語句。確保數(shù)據庫資源被釋放保證數(shù)據庫訪問在不需要使用的時候被釋放，例如連接、游標等。由于資源泄露會導致系統(tǒng)出錯而且很難捕捉到，所以我們建議建立一個資源管理模塊并且完全按照規(guī)則進行操作。禁止依賴Java和.NET的垃圾回收器來回收資源，在Java中，應該在finally塊中釋放資源來保證資源在任何環(huán)境下都會被釋放。在.NET中，則需要使用關鍵字using引入IDisposable接口來進行資源釋放，而不是直接關閉管理資源的對象。文件操作對上傳文件進行限制允許用戶上傳文件時，應對上傳文件做如下限制：上傳文件類型限制應遵循最小化原則，通過文件檢查僅允許上傳必須的文件類型。上傳文件大小限制，限制文件的容量大小范圍。文件保存路徑限制，過濾文件名或路徑名中的特殊字符（../或..\等）避免文件保存在非預期目錄中。應關閉文件上傳目錄的執(zhí)行權限，在UNIX/LINUX系統(tǒng)環(huán)境里，建議把上傳目錄掛載成獨立的邏輯盤或設置為JAIL環(huán)境。把文件名以及文件內容作為不可信的輸入對待對來自文件系統(tǒng)的所有值都應進行合適的輸入驗證，確保從文件系統(tǒng)中讀取的數(shù)據符合期望。安全的使用文件名應避免在傳遞的參數(shù)中直接使用真實的文件名，盡量使用索引值來映射實際的文件路徑。如確實需要在參數(shù)中出現(xiàn)文件名，則盡量對文件名進行白名單檢查。禁止在參數(shù)中出現(xiàn)../、..\等特殊字串及其變形。使用文件系統(tǒng)訪問控制由于文件系統(tǒng)是一個被多個用戶共享的系統(tǒng)，這就要求以最嚴格的權限來保護保存在其中的資源。這意味著文件只應被指定的用戶訪問，而且該用戶應該被限制為最小權限，例如對文件的讀寫權限都應被限制到最低。當應用程序使用被其控制的已存在文件時，應首先驗證文件的權限和屬組，防止文件存在被篡改的許可權限。注意文件訪問競爭條件多進程或線程對同一文件進行訪問時，應采取適當?shù)募渔i策略保證文件數(shù)據在訪問過程中的一致性。安全使用臨時文件在程序初始化時以最嚴格的權限策略建立一個安全臨時文件夾，該文件夾只有該程序具備讀寫權限，其他用戶無法訪問。將所有臨時文件都存放在該文件夾中，當臨時文件使用完畢后應及時清除臨時文件。確保文件系統(tǒng)資源被釋放應保證諸如文件句柄之類的文件系統(tǒng)訪問結構在不再需要時會被及時釋放。不要依賴Java和.NET的垃圾回收器來回收資源。在Java中，應該在finally塊中釋放資源來保證資源在任何情況下都會被釋放。在.NET中，則需要使用關鍵字using引入IDisposable接口來進行資源釋放，而不是直接關閉管理資源的對象。安全特征關注應用的對象重用對于底層系統(tǒng)的對象可重用性來說，應用軟件需要提供對敏感數(shù)據使用后立即覆蓋的能力，這些敏感數(shù)據包括口令、安全密鑰、會話密鑰或者其它的高度敏感的數(shù)據。應提高代碼的重復利用率，創(chuàng)建公共函數(shù)庫（對象庫）供整個軟件程序調用。用戶訪問控制信息的機密性禁止在程序代碼和配置文件中直接明文寫入用戶名和口令等用戶訪問控制信息。這些控制信息應加密后存放在配置文件中。不要在客戶端存放敏感數(shù)據由于客戶端是不可信任的，軟件不要在客戶端存放敏感數(shù)據。特別注意在使用Cookie時不要把客戶重要信息儲存在客戶端。避免內存溢出軟件設計開發(fā)中，為防止內存溢出，應注意以下事項：在對緩存區(qū)填充數(shù)據時應進行邊界檢查，判斷是否超出分配的空間。對于數(shù)據庫查詢操作，如果查詢返回的結果較多時，應設計成分次提取。應保證系統(tǒng)資源及時釋放和服務連接的及時關閉,應顯式關閉、釋放使用過的資源（如連接對象、文件句柄等），不要依賴垃圾收集器。軟件程序應檢查每次內存分配是否失敗，并進行處理。應及時釋放內存資源，防止內存泄漏，但要避免重復內存釋放。其他可能引起內存溢出的情況?？膳渲脭?shù)據保護限制非應用軟件用戶訪問可配置數(shù)據?？刹捎孟到y(tǒng)訪問控制為配置數(shù)據文件設置嚴格的訪問權限，僅應用程序可以訪問。禁止在源代碼中寫入口令應將加密后的口令存儲在配置文件，數(shù)據庫或者其它外部數(shù)據源中。禁止將口令存儲在代碼中。把口令存儲在代碼中會導致任何人都可以獲得到存儲在代碼中的口令，同時口令寫在發(fā)布的軟件中，如果需要修改口令，則軟件必需要通過安裝程序補丁等方式替換程序文件，會造成口令難于修改。隨機數(shù)如果應用程序需要隨機數(shù)，需要找出一種合適的隨機數(shù)生成方法，要求其生成代價較小并且應滿足安全需求。在Java中，建議使用SecureRandom類生成隨機數(shù)，不要使用Random類。通常不需要設置種子數(shù)給SecureRandom，Java會自動獲取一個信息熵比較平均的值。在C和C++中，避免使用標準的隨機數(shù)函數(shù)，如rand(),srand(),srand48(),drand48(),lrand48(),random()和srandom()。在隨機數(shù)生成器中不要使用容易被猜到的種子。兩種最常見的選種錯誤是使用空種子和使用日期作為種子。（對于Java來說，SecureRandom的默認構造方法可以正確的選種）。如果操作系統(tǒng)或者應用程序使用的加密庫有一個真實的隨機源，那么應使用該隨機源。在很多Unix平臺上，從/dev/urandom讀取16字節(jié)可以給出相當高質量的隨機序列，建議從/dev/urandom獲取隨機源。使用可信的密碼算法如果應用程序需要加密、數(shù)字簽名、密鑰交換或者安全散列，應使用一個成熟的算法，自己設計的密碼算法缺乏廣泛的驗證。異常管理捕捉并處理異常：應使用結構化異常處理機制，捕捉并處理異?，F(xiàn)象。避免將應用程序置于不協(xié)調的狀態(tài)，該狀態(tài)可能會導致信息泄漏或拒絕服務攻擊。記錄詳細的錯誤信息：應在錯誤日志中記錄詳細的錯誤消息。應向服務或應用程序的客戶發(fā)送最少量的信息，確保沒有密碼或其他敏感數(shù)據。如一般性錯誤消息和自定義錯誤日志ID，隨后可以將這些信息映射到事件日志中的詳細消息。不要向客戶端泄漏信息：發(fā)生故障時，嚴禁向客戶端泄漏信息，禁止暴露的內容包括函數(shù)名以及調試內部版本時出問題的詳細信息。應向客戶端返回一般性錯誤消息。可以將應用程序設置為不向遠程用戶顯示詳細錯誤信息，也可以選擇將錯誤重定向到應用程序頁。應捕捉所有未處理異常并將它們發(fā)送到一般錯誤頁的頁級別或應用程序級別上，創(chuàng)建全局錯誤處理程序。應用安全設計規(guī)范應用安全規(guī)劃將應用系統(tǒng)劃分為多個相對獨立的邏輯單元，按照邏輯單元的安全要求，規(guī)劃邏輯單元的部署區(qū)域以及訪問方式，確保邏輯單元的邊界訪問安全。數(shù)據安全等級劃分對應用系統(tǒng)的數(shù)據進行分析，區(qū)分出普通數(shù)據、敏感數(shù)據和保密數(shù)據等類型。普通數(shù)據：凡是不涉及敏感信息的數(shù)據都屬于普通數(shù)據，系統(tǒng)中大部分的數(shù)據都是屬于普通數(shù)據，普通數(shù)據允許采用明文傳輸和明文存儲。敏感數(shù)據：敏感數(shù)據涉及到重要信息，為防止在傳輸過程中被攔截竊取或遭到篡改，要求敏感數(shù)據在客戶端和服務端之間必須采用SSL/TLS協(xié)議進行傳輸，保證數(shù)據的傳輸安全。敏感數(shù)據除了傳輸需要加密外，一般還要求對敏感數(shù)據新增和變更操作進行審計。如：信用卡信息、支付交易等屬于敏感數(shù)據。保密數(shù)據：凡是不允許使用明文存儲的數(shù)據都屬于保密數(shù)據，保密數(shù)據除了必須滿足敏感數(shù)據對數(shù)據傳輸進行加密和審計的要求外，還必須按照保密性的要求，在數(shù)據存儲之前對數(shù)據進行加密，數(shù)據庫或文件中僅存儲加密后的數(shù)據。如：用戶口令、支付密碼、信用卡密碼等屬于保密數(shù)據。數(shù)據庫規(guī)劃用戶權限合理規(guī)劃數(shù)據庫用戶，避免因為權限分配不當引起的數(shù)據安全問題。數(shù)據源設計為事務執(zhí)行時間較長的操作分配單獨的數(shù)據源，避免因為事務長時間暫用數(shù)據連接而對其它功能造成影響。外部系統(tǒng)訪問外部系統(tǒng)需要直接訪問應用的數(shù)據時，應單獨分配一個用戶，并按照最小權限原則僅分配外部系統(tǒng)所需的最小訪問權限。角色劃分對外網類應用，必須預先定義外網用戶角色類型、各類角色的應用場景，并按照缺省最小權限原則劃分角色權限。URL規(guī)劃對外網類應用，按照用戶角色對應權限類型對系統(tǒng)URL進行規(guī)劃，各種不同權限功能對應的URL按照各種不同的統(tǒng)一的URL規(guī)則進行定義，具有不同訪問權限要求的URL路徑規(guī)則不應混合在一起。如： 用戶個人空間對應功能都在/user/路徑下管理員對應的功能都在/admin/路徑下程序文件目錄規(guī)劃數(shù)據及程序分離遵守數(shù)據文件和程序文件分離的原則，在應用部署根及子目錄下不應存放任何數(shù)據文件。靜態(tài)程序資源靜態(tài)程序資源應統(tǒng)一存放在指定的目錄下，在靜態(tài)程序資源目錄下不要存放任何動態(tài)資源、可執(zhí)行文件、數(shù)據及任何無關資源。程序文件分類程序文件分為可直接被客戶端請求訪問的文件以及無法從客戶端直接訪問的文件，應對程序文件進行劃分，將不同的程序文件存放在不同的目錄下。如果不希望某個程序文件能被客戶端輸入文件路徑后被直接，應該將這些文件放在WEB-INF目錄下。否則WEB-INF目錄之外的文件都可以通過客戶端輸入URL直接訪問或下載。CookieCookie的使用必須做統(tǒng)一的分析和管理，并按照Cookie存儲的數(shù)據重要程序及使用場景做劃分。禁止被客戶端Javascript及applet等操作必須通過Https在客戶端和服務端之間傳輸僅對當前會話有效，瀏覽器關閉后即失效允許存儲在客戶端本地文件安全文件存儲系統(tǒng)運行過程中生成的正式文件必須存儲在專門的文件服務器上，并要設置安全訪問策略。文件操作外網文件操作必須通過HTTP協(xié)議提供的WebDAV完成，不要使用FTP等文件傳輸協(xié)議。并且不允許直接對外開放文件服務器的訪問權限，文件訪問因通過應用服務器中轉完成。文件類型必須明確指定應用系統(tǒng)中允許上傳的文件類型。第三方組件安全組件兼容性所以引入的第三方組件都必須確保組件與平臺之間的兼容性，避免引入組件后引起平臺及現(xiàn)有組件崩潰、無法運行、出現(xiàn)BUG等問題。組件安全及成熟度對第三方組件的成熟度及安全做評估，確保第三方組件不存在已知的未解決的安全漏洞，并且有成熟的社區(qū)在對組件升級和維護，當組件出現(xiàn)新的安全漏洞時，能被及時解決。組件配置必須按照安全的方式對組件進行集成和配置，避免出現(xiàn)因為配置和使用不當引起的安全漏洞。WebService1．必須對WebService接口的調用必須進行認證,認證就是確定誰在調用WebService，并且證實調用者身份。方案：可以通過在消息頭中增加用戶名和口令，作為認證憑據；對于安全性要求不高、只向同一信任域內其他主機開放的WebService接口，可以通過簡單的IP認證來實現(xiàn)接口的認證（只有服務器端指定IP地址的客戶端才允許調用，IP地址可配置）。2.如果調用者的權限各不相同，那么必須對WebService接口的調用進行鑒權，鑒權就是判斷調用者是否有權限調用該WebService接口。方案：可以通過Axis的handler對調用進行鑒權。3.通過WebService接口傳遞敏感數(shù)據時，必須保障其機密性。方案：采用HTTPS安全協(xié)議。使用axis2開發(fā)WebService，使用rampart-1.6.1.mar安全組件，并且該組件需要依賴wss4j等組件。4.通過WebService接口傳遞重要的交易數(shù)據時，必須保障其完整性和不可抵賴性，重要的交易數(shù)據，如轉賬時涉及的“轉入賬號”、“轉出賬號”、“金額”等。5.如果WebService只對特定的IP開放，那么必須對調用WebService接口的客戶端IP進行鑒權，只有在IP地址白名單中的客戶端才允許調用，IP地址白名單可配置。6.對WebService接口調用進行日志記錄，日志內容包括但不限于如下內容：調用時間、操作類型、調用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調用者的用戶標識、受影響的個體（數(shù)據、資源）、成功或失敗標識。7.必須對WebService提交的參數(shù)進行輸入校驗。RESTfulWebServiceRESTfulWebService（也稱為RESTfulWebAPI）是一個使用HTTP并遵循REST原則的Web服務。1.對RESTfulWebService的調用必須進行認證，認證就是確定誰在調用RESTfulWebService，并且證實調用者身份。方案：客戶端發(fā)起的Restful請求需要在消息頭帶Authorization字段，內容填BasicBase64(user:pass)，服務端對user和passwd進行認證。注意：user和pass必須加密保存在配置文件或數(shù)據庫中，不能寫死在代碼中；傳輸時采用https安全協(xié)議。對于安全性要求不高、只向同一信任域內其他主機開放的WebService接口，可以通過簡單的IP認證來實現(xiàn)接口的認證（只有服務器端指定IP地址的客戶端才允許調用，IP地址可配置）。2.調用者的權限各不相同，那么必須對RESTfulWebService的調用進行鑒權，權就是判斷調用者是否有權限調用該RESTfulWebService。3.通過RESTfulWebService傳遞敏感數(shù)據時，必須保障其機密性，采用HTTPS安全協(xié)議。4.如果RESTfulWebService只對特定的IP開放，那么必須對調用RESTfulWebService的客戶端IP進行鑒權，只有在IP地址白名單中的客戶端才允許調用，IP地址白名單可配置。5.對RESTfulWebService調用進行日志記錄，日志內容包括但不限于如下內容：調用時間、操作類型、調用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調用者的用戶標識、受影響的個體（數(shù)據、資源）、成功或失敗標識。6.必須對RESTfulWebService提交的參數(shù)進行輸入校驗。應用安全關注點圖1典型的Web安全技術框架圖1顯示了典型的Web應用安全的技術框架和安全技術點，這些安全技術點，貫穿整個Web設計開發(fā)過程。上圖各個區(qū)域中存在任何一點薄弱環(huán)節(jié)，都容易導致安全漏洞。由于HTTP的開放性，Web應用程序必須能夠通過某種形式的身份驗證來識別用戶，并確保身份驗證過程是安全的，同樣必須很好地保護用于跟蹤已驗證用戶的會話處理機制。為了防止一些惡意輸入，還要對輸入的數(shù)據和參數(shù)進行校驗。另外還要考慮Web系統(tǒng)的安全配置，敏感數(shù)據的保護和用戶的權限管理，以及所有操作的安全審計。當然還要考慮代碼安全，以及其他方面的威脅。表1列出了一些Web缺陷類別，并針對每類缺陷列出了由于設計不當可能會導致的潛在問題。針對這些潛在的問題，本規(guī)范中有相應的解決措施。表1Web應用程序缺陷和由于不良設計可能導致的問題缺陷類別由于不良設計可能導致的問題身份驗證身份偽造、口令破解、權限提升和未授權訪問。會話管理通過捕獲導致會話劫持和會話偽造。權限管理訪問機密或受限數(shù)據、篡改和執(zhí)行未授權操作。配置管理未授權訪問管理界面、更新配置數(shù)據、訪問用戶帳戶和帳戶配置文件。敏感數(shù)據機密信息泄漏和數(shù)據篡改。加密技術未授權訪問機密數(shù)據或帳戶信息。安全審計未能識別入侵征兆、無法證明用戶的操作，以及在問題診斷中存在困難。輸入檢驗通過嵌入查詢字符串、窗體字段、Cookie和HTTP標頭中的惡意字符串所執(zhí)行的攻擊。包括命令執(zhí)行、跨站點腳本編寫(XSS)、SQL注入和緩沖區(qū)溢出攻擊等。參數(shù)操作路徑遍歷攻擊、命令執(zhí)行、此外還有跳過訪問控制機制、導致信息泄露、權限提升和拒絕服務。異常管理拒絕服務和敏感的系統(tǒng)級詳細信息泄露。應用安全限制應對方案外網隔離前置機涉及到外網訪問的應用，必須將與外網交互的應用部署在外網前置機，外部用戶或系統(tǒng)只能訪問前置機服務。內網應用當外網應用需要與內網業(yè)務系統(tǒng)交互時，必須在內網部署相關應用，并通過內網應用與業(yè)務系統(tǒng)交互。數(shù)據庫外網不允許部署數(shù)據庫，所有的數(shù)據庫都部署在內網，外網應用通過強隔離裝置使用JDBC訪問部署在內網的數(shù)據庫。外網應用不允許從外網直接連接內網關鍵業(yè)務系統(tǒng)數(shù)據庫，如：禁止對外網站直接通過JDBC連接營銷系統(tǒng)生產庫。外網文件操作外網不部署FTP等服務，當外網應用需要文件系統(tǒng)支持時，通過WebDAV來替代FTP。并且當用戶操作需要訪問文件時，文件訪問操作應通過應用系統(tǒng)進行文件操作的中轉，不要讓客戶端通過文件訪問協(xié)議直接連接文件系統(tǒng)。WebDAV（Web-basedDistributedAuthoringandVersioning）一種基于HTTP1.1協(xié)議的通信協(xié)議。它擴展了HTTP1.1，在GET、POST、HEAD等幾個HTTP標準方法以外添加了一些新的方法，使HYPERLINK應用程序可直接對WebServer上的文件讀寫，并支持寫文件鎖定(Locking)及解鎖(Unlock)，還可以支持文件的HYPERLINK版本控制。正向和反向隔離裝置（國網系統(tǒng)）正向和反向隔離裝置用于調度控制區(qū)(I/II區(qū))與管理信息區(qū)(III區(qū))數(shù)據交互的時候要用的設備。正向隔離裝置用于安全區(qū)I/II到安全區(qū)III的單向數(shù)據傳遞。反向隔離裝置用于安全區(qū)III到安全區(qū)I/II的單向數(shù)據傳遞。正向隔離裝置針對I/II區(qū)到III區(qū)通信內容規(guī)定，南瑞SysKeeper-2000網絡安全隔離設備提供了豐富的通信工具軟件和API函數(shù)接口，方便用戶進行二次系統(tǒng)隔離改造。反向隔離裝置根據全國電力二次安全防護的要求，需要將純文本文件中單字符的ASCII碼（非控制字符）轉換為對應的雙字節(jié)碼，并能正常顯示。南瑞SysKeeper－2000反向隔離裝置提供了專用發(fā)送軟件在發(fā)送文本文件數(shù)據時，自動將半角字符轉換為全角字符。SysKeeper-2000反向隔離裝置對收到的數(shù)據進行純文本的識別，如果數(shù)據包中數(shù)據為合法的純文本，反向隔離裝置都會按照編碼范圍正確的識別，保證進入內網的數(shù)據為純文本數(shù)據。應用安全開發(fā)規(guī)范Java及Web安全編程規(guī)范不信任未知JAVA編程時同樣需要遵守任何輸入都是不可信的原則。所有的輸入都是不安全的，在使用前都應進行檢查、驗證或者過濾。這里的輸入不僅僅指正常情況下的用戶輸入，還包括從文件獲取的內容、從協(xié)議的數(shù)據包中獲取的內容，從環(huán)境變量、注冊表等獲取的輸入。數(shù)據層開發(fā)預編譯語句數(shù)據層最大的安全風險是SQL注入，SQL注入指的是利用現(xiàn)有應用程序，將(惡意)的SQL命令注入到后臺數(shù)據庫引擎執(zhí)行的攻擊方法。沒有對用戶輸入的數(shù)據進行驗證是Sql注入攻擊得逞的主要原因。用戶可以提交一段數(shù)據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數(shù)據。為防御SQL注入攻擊，必須采用預編譯的方式執(zhí)行SQL語句或存儲過程。正確：StringquerySql=“selectusernamefromuserwhereid=?”錯誤：Stringid=“abc”StringquerySql=“selectusernamefromuserwhereid=‘”+id+“’”一段可能產生SQL注入的代碼如下：Stringuser=request.getParameter("username");Stringpass=request.getParameter("password");Stringquery="SELECTidFROMusersWHEREusername="+user+"ANDpassword="+pass;Statementstmt=con.createStatement(query);ResultSetrs=con.executeQuery(query);if(rs.next()){//登錄成功intid=rs.getInt(1);…}else{//登錄失敗...}正確的做法如下：Stringuser=request.getParameter("username");Stringpass=request.getParameter("password");Stringquery="SELECTidFROMusersWHEREusername=?ANDpassword=?";PreparedStatementstmt=con.prepareStatement(query);stmt.setString(1,user);stmt.setString(2,pass);ResultSetrs=stmt.executeQuery();if(rs.next()){//登錄成功intid=rs.getInt(1);...}else{//登錄失敗...}如果沒有使用PreparedStatement類就一定要對輸入做特殊字符過濾，過濾的字符至少包括：’（單引號）;（分號）--（兩個減號）。數(shù)據驗證在執(zhí)行SQL或存儲過程之前，必須確保傳入的參數(shù)變量都已經過驗證符合規(guī)則或權限約束。會話管理會話創(chuàng)建在用戶認證成功后，應先將之前的用戶會話銷毀，然后重新為用戶生成新的會話，保證認證成功前后，用戶會話ID不一樣，并且保證不會將數(shù)據存放到未認證通過的會話中。會話創(chuàng)建過程應嚴格遵守以下的步驟：接收提交的用戶名和密碼驗證通過調用session.invalidate()方法注銷當前會話調用request.getSession(true)重新生成一個新的會話將用戶名等會話信息放入新生成的session對象中存放會話數(shù)據存儲不要將除了標識當前用戶身份之外的其它數(shù)據存放到用戶的Session中。會話注銷要提供用戶注銷功能，并且應保證以下的代碼在注銷過程中被調用：session.invalidate()Cookie臨時Cookie臨時Cookie指的是沒有指定Expire時間，當瀏覽器關閉后，Cookie就失效。如果要使用Cookie，因優(yōu)先選擇使用臨時Cookie，只把Cookie保存在瀏覽器的內存中。response.setHeader(“Set-Cookie”,”name=value;”);本地Cookie本地Cookie指的是在生成Cookie時，設置了Expire時間，只有當Expire時間到了Cookie才會失效，這種Cookie會被存儲到客戶端本地，由于存儲了用戶的信息，因此這種類型的Cookie有較高的風險，不要將重要的數(shù)據存儲在本地Cookie中。response.setHeader(“Set-Cookie”,”name=value;expire=Thu,01-Jan-201400:00:01GMT;”);Cookie訪問如果希望禁止在客戶端通過Javascript和Applet等技術訪問和操作Cookie中的數(shù)據，可以在生成Cookie時，在其中加入HttpOnly的屬性。response.setHeader(“Set-Cookie”,”name=value;HTTPOnly”);Cookie傳輸如果在Cookie中存儲了關鍵信息，希望Cookie僅當在Https協(xié)議下的請求中被傳輸?shù)椒斩?，可以在生成Cookie時，在其中加入secure的屬性。response.setHeader(“Set-Cookie”,”name=value;secure”);輸入驗證數(shù)據格式驗證驗證提交的數(shù)據是否符合業(yè)務規(guī)則及格式約束，如：數(shù)據格式、數(shù)據長度、數(shù)據類型。Token驗證對涉及到數(shù)據提交操作的請求，必須采用POST方式提交form表單數(shù)據，并在提交的表單中附加Token，通過在服務端驗證Token的方式驗證請求的合法性，避免由于URL猜測引擎的CSRF漏洞攻擊。輸入文件名的驗證如果需要從調用方接收輸入文件名，要確保文件名具有嚴格的格式，以便可以確定它是否有效。一段有漏洞的程序：String=request.getParameter("");Stringcontent=request.getParameter("content");fw=new(newFile(“/home/y/share/templates/”+));fw.write(content);應該對文件名做嚴格的檢查，比如使用正則表達式，限定文件名只能包括字母和數(shù)字。輸出處理使用Struts標簽庫輸出在可能的情況下頁面上的變量應都采用Struts標簽輸出，Struts標簽本身具有特殊字符編碼的功能。bean:write如果通過bean:write輸出變量，除特殊情況下確實需要輸出HTML編碼，否則都應該使用filter屬性值為true。缺省情況下，該值為true。變量輸出前編碼如果未采用標簽輸出變量，而是采用直接代碼的方式，如request.getParameter(“param”)、request.getAttribute(“key”)或服務端傳來的<%=var%>等方式輸出變量時，必須在變量輸出之前，對變量進行編碼轉換。在HTML標簽及屬性中輸出在HTML標簽及屬性中輸出變量時，必須對變量進行符合OWASP標準的HtmlEncode編碼操作<div>endoceForHTML($var)</div><ahref=#>endoceForHTML($var)</a><divname=”endoceForHTML($var)”></div>在HTML事件中輸出在HTML事件中輸出變量時，必須對變量進行符合OWASP標準的JavascriptEncode編碼操作。<ahref=#onclick=”f(‘encodeForJavascript($var)’)”>link</a>在<script>標簽中輸出在script標簽中輸出時，首先應該確保輸出的變量處于引號中，并且通過符合OWASP標準的JavascriptEncode編碼操作對變量進行編碼。<script>vartemp=”encodeForJavascript($var)”;</script>在CSS中輸出CSS代碼中的XSS攻擊形式也有很多種，如：style、styleattribute等都可能引起XSS攻擊。應盡可能避免在<style>標簽內部、html中的style屬性中、css文件中輸出變量。如果確實有需要輸出變量的情況，應在輸出前對編碼進行符合OWASP標準的cssEncode操作。<style>li{list-style-image:url(“javascript:alert(‘encodeForCSS($var)’)”);}</style>在地址中輸出對URL中的路徑或查詢參數(shù)中輸出變量，應該對變量使用符合OWASP標準的URLEncode編碼操作<ahref=”/root/path?param=encodeForURL($var)”>link</a>富文本輸出富文本的數(shù)據類型比較特殊，富文本屬于一段比較完整的HTML代碼，在輸出時和使用時也不會被拼接到某個特殊的位置。因此如果當前請求中存在包含HTML的富文本內容，不能直接對特殊字符進行編碼或轉義，應對富文本內容進行過濾，保證輸出到客戶端的的富文本中事件代碼、<iframe>、<script>、<base>、<from>等危險的HTML標簽被嚴格禁止，僅保留安全的標簽存在。encodeForRichHtml($var)敏感信息處理數(shù)據加密存儲將不允許明文存儲的數(shù)據加密后在存儲到數(shù)據庫或文件中，加密算法不能采用自己實現(xiàn)的算法，應采用MD5、SHA、DES等經過驗證的加密算法進行加密。如：用戶口令，必須使用不可逆的加密算法加密后在存儲在數(shù)據庫中。數(shù)據傳輸加密將涉及到以下情況的請求通過Https協(xié)議發(fā)送涉及到用戶登錄驗證的請求涉及到會話生成的請求涉及到用戶密碼傳輸及修改的請求涉及到支付操作的請求涉及到重要及敏感數(shù)據的請求禁止緩存服務端和客戶端都禁止緩存敏感數(shù)據。在服務端，當敏感數(shù)據使用完后，應將數(shù)據從內存中刪除。在客戶端，包含敏感數(shù)據的HTTPS請求，要設置以下的頭信息，禁止瀏覽器緩存頁面數(shù)據，HTTP頭信息代碼如下：Cache-Control:no-cache,no-store;異常信息處理不允許將異常信息拋給客戶端顯示，否則可能造成服務端信息泄露。如果系統(tǒng)功能出現(xiàn)異常，應跳轉到專門的異常頁面，并將友好的提示信息提示給用戶，而不是將異常信息顯示給用戶，并且返回給客戶端HTTP響應結果為500。特殊頁面跳轉404-路徑不存在當用戶訪問了一個系統(tǒng)中不存在的路徑時，應將請求跳轉到指定的404處理頁面，提示用戶訪問的路徑不存在，并返回給瀏覽器HTTP404編碼。403-禁止訪問當用戶訪問了一個無訪問權限的路徑時，應將請求跳轉到指定的403處理頁面，提示用戶無權訪問，并返回給瀏覽器HTTP403編碼。500-內部錯誤當用戶操作引起系統(tǒng)服務端應用異常時，應將請求跳轉到指定的500處理頁面，提示用戶當前系統(tǒng)出現(xiàn)異常，并返回給瀏覽器HTTP500編碼。文件操作臨時文件系統(tǒng)運行過程中生成的臨時文件必須存放在應用部署根目錄之外。并且在使用完后要立即刪除，臨時文件不允許重復使用。臨時文件名必須采用足夠長度的隨機算法生成。文件上傳文件路徑控制對上傳的文件需要在服務端將路徑轉為系統(tǒng)絕對路徑，然后對比當前路徑是否屬于允許存儲的路徑之下。文件類型控制禁止上傳可執(zhí)行文件，如：jsp,asp,aspx,exe,bat等類型的文件，通過白名單的方式僅僅允許上次指定類型的文件。文件大小控制必須按照要求限制上傳到服務器上文件的大小目錄文件數(shù)量不要將大量的文件上傳并存儲在統(tǒng)一個目錄下，應該按照一定的規(guī)則，將文件分散存放到不同的目錄。文件名保存在服務器上的文件名必須經過修改，文件上傳到服務器上后，采用非常隨機的算法（如：GUID）重新生成文件名。文件下載下載驗證每個文件下載之前都應通過權限驗證，否則可能引起通過修改URL參數(shù)即可下載任意文件的漏洞。文件路徑控制所有下載的文件，都必須驗證待下載文件路徑是否出在允許下載文件的路徑范圍內。資源釋放所有涉及到IO操作的資源都應該在finally塊中釋放，保證資源在任何環(huán)境下都會被釋放。內存控制大對象如果要加載大對象到內存中，應盡可能減少大對象在內存中的存活時間，使用完后立即釋放，并將對象應用設置為NULL，對于大對象的內存回收不應太過依賴內存垃圾回收機制。數(shù)據庫操作要限制數(shù)據庫操作的每個請求返回的結果集最大值，如果需要讀取的結果集記錄數(shù)過大，應采用多次分頁讀取的方式，分批從數(shù)據庫中讀取數(shù)據。外部程序調用漏洞應該避免在程序中調用系統(tǒng)命令，如果必須使用系統(tǒng)命令，應對輸入參數(shù)做嚴格的過濾，比如一段存在漏洞的程序如下：Stringip=request.getParameter(“ip”);Processp=Runtime.getRuntime().exec(“/bin/shnslookup”+ip);應使用正則表達式對輸入的參數(shù)（IP）做嚴格過濾，否則用戶可以提交如下格式的IP數(shù)據：;[自己的命令]來執(zhí)行自己的命令。整數(shù)溢出整數(shù)的范圍是[-2^31,+2^31-1]，又有以下等式成立：-2^31==2^31+1以上范圍和等式在Java中同樣成立，所以整數(shù)溢出同樣在存在于Java，由于整數(shù)的溢出導致流程的改變。一