1、WEB 應用系統安全規范目錄WE而用系統安全規范 11 概述 21.1 目的 21.2 適用范圍22 范圍 33 名詞解釋 34 WE凱發安全規范 34.1 WEB 應用程序體系結構和安全34.2 WEB 安全編碼規范54.2.1 區分公共區域和受限區域 54.2.2 對身份驗證cookie 的內容進行加密 54.2.3 限制會話壽命 64.2.4 使用 SSL 保護會話身份驗證Cookie 64.2.5 確保用戶沒有繞過檢查 64.2.6 驗證從客戶端發送的所有數據 64.2.7 不要向客戶端泄漏信息 64.2.8 記錄詳細的錯誤信息 64.2.9 捕捉異常 64.2.10 不要信任HTTP

2、 頭信息 74.2.11 不要使用HTTP-GET 協議傳遞敏感數據 74.2.12 不要在永久性cookie 中存儲敏感數據 74.2.13 對數據進行加密或確保通信通道的安全 74.2.14 SQL 語句的參數應以變量形式傳入 74.2.15 頁面中的非源代碼內容應經過URI 編碼 84.2.16 頁面中拼裝的腳本應校驗元素來源的合法性 84.2.17 頁面請求處理應校驗參數的最大長度 84.2.18 登錄失敗信息錯誤提示應一致 84.2.19 避免頁面上傳任意擴展名的文件 84.2.20 避免接受頁面中的主機磁盤路徑信息 84.2.21 第三方產品的合法性 95 系統部署安全規范 95.

3、1 部署架構和安全95.1.1 網絡基礎結構組件 95.1.2 部署拓撲結構 105.2 部署操作安全規范105.2.1 確保管理界面的安全 105.2.2 確保配置存儲的安全 105.2.3 單獨分配管理特權 115.2.4 使用最少特權進程和服務帳戶 115.2.5 盡量避免存儲機密 115.2.6 不要在代碼中存儲機密 115.2.7 不要以純文本形式存儲數據庫連接、密碼或密鑰 115.2.8 限制主機上WEB 系統啟動用戶的權限115.2.9 隱藏后臺調試信息115.2.10 密碼加密存儲 125.2.11 隱藏重要配置參數信息 125.2.12 隱藏日志文件 125.2.13 禁用

4、WebDAV ，或者禁止不需要的HTTP 方法 125.2.14 保證管理平臺、測試賬號口令強度 125.2.15 定期核查文件上傳路徑、日志路徑中是否存在木馬 125.2.16 及時刪除應用系統臨時文件 135.2.17 重要系統隔離 136 安全審計 136.1 審核并記錄跨應用層的訪問 136.2 考慮標識流 136.3 記錄關鍵事件 146.4 確保日志文件的安全 146.5 定期備份和分析日志文件 147 規范更新機制 148 規范的執行 149 參考資料 151 概述1.1 目的為規范我司Java Web 應用編碼和部署的安全控制和管理，特制定本規范，并作為安全檢查及考核的參考依據

5、。1.2 適用范圍本規范適用于我司所有在線Java業務系統、測試系統的 WEB應用。本規范可作為其他非WEB 應用的編碼和部署安全辦法參考。資料2 范圍本規范中列出的是常見安全措施和高風險的漏洞，在系統開發與系統部署的過程中，對本規范未能盡述的必要安全措施，仍應予以采用。本規范每年復審一次，其它時候也可以根據需要進行修訂并發布。本規范的解釋權和修改權歸屬信息技術部。3 名詞解釋驗證：通訊實體（例如，客戶端和服務器）彼此驗證，以經過訪問授權的特定標識為依據。資源的訪問控制： 資源的交互僅限于某些用戶或程序的集合，其目的是對完整性，保密性或可用性實施強制約束。數據完整性：檢驗信息是否被第三方（非信

6、息源的其它實體）修改。例如，處于開放網絡 環境中的數據接收方必須能夠檢測并丟棄那些在傳遞過程中被修改過的消息。機密性或數據隱私： 確保信息僅對經過訪問授權的用戶可用。不可否認：對用戶進行檢驗，讓他無法否認自己進行過的活動。審核：捕獲一個安全相關事件的防篡改記錄，目的是評估安全策略和機制的有效性。4 Web開發安全規范4.1 Web應用程序體系結構和安全資料應用程HTTP是無國界的，這意味著跟蹤每位用戶的會話狀態將成為應用程序的責任。序必須能夠通過某種形式的身份驗證來識別用戶。由于所有后續授權決策都要基于用戶的標識，因此，身份驗證過程必須是安全的，同樣必須很好地保護用于跟蹤已驗證用戶的會話處理機

7、制。設計安全的身份驗證和會話管理機制僅僅是Web應用程序設計人員和開發人員所面臨的眾多問題中的兩個方面。由于輸入和輸出數據要在公共網絡上進行傳輸，因此還會存在其他挑戰。防止參數操作和敏感數據泄漏也是另外一些重要問題。Web應用程序安全設計是根據應用程序漏洞類別進行組織的。實際經驗表明，如果這些領域的設計存在薄弱環節，將會導致安全漏洞。 下表列出了漏洞的類別，每個類別都突出顯示了由于設計不當可能會導致的潛在問題。漏洞類別由于設計不當而引起的潛在問題輸入驗證嵌入到查詢字符串、表單字段、cookie和HTTP頭中的惡意字符串的攻擊。這些攻擊包括命令執行、跨站點腳本（XSS）、SQL注入和緩沖區溢出攻

8、擊。身份驗證標識欺騙、密碼破解、特權提升和未經授權的訪問。授權訪問保密數據或受限數據、篡改數據以及執行未經授權的操作。配置管理對管理界面進行未經授權的訪問、具有更新配置數據的能力以及對用戶帳戶和帳戶配置文件進行未經授權的訪問。敏感數據泄露保密信息以及篡改數據。會話管理捕捉會話標識符，從而導致會話劫持及標識欺騙。加密訪問保密數據或帳戶憑據，或二者均能訪問。參數操作路徑遍歷攻擊、命令執行以及繞過訪問控制機制，從而導致信息泄漏、特權提 升和拒絕服務。異常管理拒絕服務和敏感的系統級詳細信息的泄漏。審核和記錄不能發現入侵跡象、不能驗證用戶操作，以及在診斷問題時出現困難。針對上述漏洞的應用程序設計指南如下

9、表:類別規范指南輸入驗證不要信任輸入；應考慮集中式輸入驗證。不要依賴于客戶端驗證。 注意標準化問題。 限制、拒絕和凈化輸入。 驗證類型、 長度、格式和范圍。身份驗證將站點分割為匿名區域、標識區域和通過身份驗證的區域。使用強密碼。支持 密碼有效期和帳戶禁用。不要存儲憑據（應使用帶有salt的單向哈希）。加密通信通道，以保護身份驗證令牌。僅通過HTTPS 連接傳遞表單身份驗證cookie 。授權使用最少特權帳戶。 考慮授權粒度。實施分別授權。限制用戶訪問系統級資源。配置管理使用最少特權進程和服務帳戶。不要以純文本形式存儲憑據。在管理界面上使 用強身份驗證和授權。/、要使用LSA。遠程管理時要確保通

10、信通道的安全。避免在 Web空間中存儲敏感數據。敏感數據避免存儲機密。對網絡上傳輸的敏感數據進行加密。確保通信通道的安全。對敏感數據存儲提供強訪問控制。不要在永久性cookie中存儲敏感數據。不要使用HIIP-GET 協議傳遞敏感數據。會話管理限制會話壽命。確保通道的安全。對身份驗證cookie的內容進行加密。保護會話狀態，以防止未經授權的訪問。加密不要自創加密算法。使用可靠并經過測試的平臺功能。將未加密的數據存儲在算法附近。使用正確的算法和密鑰大小。避免密鑰管理（使用DPAPI ）。定期回收密鑰。在受限區域存儲密鑰。參數操作對敏感的cookie狀態加密。/、要信任客戶端可以操作的字段（如查詢

11、字符串、表單字段、cookie或HTTP頭）。驗證從客戶端發送的所有數據。異常管理使用結構化的異常處理機制。不要泄漏敏感的應用程序實施細節。不要記錄保 密數據，如密碼。考慮使用集中式的異常管理框架。審核和記錄識別懷有惡意的行為。了解好的數據流應該是什么樣子。在所有應用層中審核 和記錄活動。確保日志文件訪問的安全。定期備份和分析日志文件。4.2 We b安全編碼規范4.2.1 區分公共區域和受限區域站點的公共區域允許任何用戶進行匿名訪問。受限區域只能接受特定用戶的訪問，而且用戶必須通過站點的身份驗證。考慮一個典型的零售網站。 您可以匿名瀏覽產品分類。當您向購物車中添加物品時，應用程序將使用會話標

12、識符驗證您的身份。最后，當您下訂單時， 即可執行安全的交易。這需要您進行登錄，以便通過 SSL驗證交易。將站點分割為公共訪問區域和受限訪問區域， 可以在該站點的不同區域使用不同的身份 驗證和授權規則，從而限制對 SSL的使用。使用 SSL會導致性能下降，為了避免不必要 的系統開銷，在設計站點時，應該在要求驗證訪問的區域限制使用SSL。4.2.2 對身份驗證 cookie的內容進行加密即使使用 SSL,也要對 cookie內容進行加密。如果攻擊者試圖利用XSS攻擊竊取cookie,這種方法可以防止攻擊者查看和修改該cookie。在這種情況下，攻擊者仍然可以使用 cookie 訪問應用程序，但只有

13、當cookie 有效時，才能訪問成功。4.2.3 限制會話壽命縮短會話壽命可以降低會話劫持和重復攻擊的風險。會話壽命越短，攻擊者捕獲會話 cookie 并利用它訪問應用程序的時間越有限。4.2.4 使用 SSL 保護會話身份驗證Cookie不要通過HTTP 連接傳遞身份驗證cookie。 在授權 cookie 內設置安全的cookie 屬性，以便指示瀏覽器只通過HTTPS 連接向服務器傳回cookie。4.2.5 確保用戶沒有繞過檢查確保用戶沒有通過操作參數而繞過檢查。最終用戶可以通過瀏覽器地址文本框操作URL 參數。 例如， URL 地址 http:/www.<YourSite>

14、/<YourApp>/sessionId=10 包含一個值10，通過將該值更改為其他隨機數字，可以得到不同的輸出。應確保在服務器端代碼中執行上述檢查，而不是在客戶端的JavaScript 中檢查，因為可以在瀏覽器中禁用JavaScript。4.2.6 驗證從客戶端發送的所有數據限制可接受用戶輸入的字段，并對來自客戶端的所有值進行修改和驗證。如果表單字段中包含預定義值，用戶可以更改這些值，并將其傳回服務器，以得到不同的結果。只接受已知的有益數據。例如， 如果輸入字段面向一個州，那么只有與該州郵政編碼匹配的輸入才能被接受。4.2.7 不要向客戶端泄漏信息發生故障時，不要暴露將會導致信息

15、泄漏的消息。例如， 不要暴露包括函數名以及調試內部版本時出問題的行數（該操作不應在生產服務器上進行）的堆棧跟蹤詳細信息。應向客戶端返回一般性錯誤消息。4.2.8 記錄詳細的錯誤信息向錯誤日志發送詳細的錯誤消息。應該向服務或應用程序的客戶發送最少量的信息，如一般性錯誤消息和自定義錯誤日志ID,隨后可以將這些信息映射到事件日志中的詳細消息。確保沒有記錄密碼或其他敏感數據。4.2.9 捕捉異常使用結構化異常處理機制，并捕捉異常現象。這樣做可以避免將應用程序置于不協調的狀態， 這種狀態可能會導致信息泄漏。它還有助于保護應用程序免受拒絕服務攻擊。確定如何在應用程序內部廣播異常現象，并著重考慮在應用程序的

16、邊界會發生什么事情。4.2.10 不要信任HTTP 頭信息HTTP 頭在 HTTP 請求和響應開始時發送。應確保 Web 應用程序的任何安全決策都不是基于 HTTP 頭中包含的信息，因為攻擊者很容易操作HTTP 頭。例如，HTTP 頭中的“refere序段包含發出請求的網頁的URL。不要基于“refere序段值作出任何安全決策，以檢查發出請求的頁面是否由該Web 應用程序生成，因為該字段很容易偽造。4.2.11 不要使用HTTP-GET 協議傳遞敏感數據應避免使用HTTP-GET 協議存儲敏感數據，因為該協議使用查詢字符串傳遞數據。使用查詢字符串不能確保敏感數據的安全性，因為查詢字符串經常被服

17、務器記錄下來。4.2.12 不要在永久性cookie 中存儲敏感數據避免在永久性cookie 中存儲敏感數據。如果存儲的是純文本數據，最終用戶能夠看到并修改該數據。如果對其加密，必須考慮密鑰管理。例如，如果用于加密cookie 中的數據的密鑰已過期且已被回收，則新密鑰不能對客戶端通過瀏覽器傳遞的永久性cookie 進行解密。4.2.13 對數據進行加密或確保通信通道的安全如果在網絡上向客戶端發送敏感數據，應對數據進行加密或確保通信通道的安全。通常的做法是在客戶端與 Web服務器之間使用 SSL。服務器間的通信通常使用IPSec。要確保通過多重中間件傳輸的敏感數據的安全性，如Web 服務簡單對象

18、訪問協議（SOAP） 消息，應使用消息級加密。4.2.14 SQL 語句的參數應以變量形式傳入（一）在對數據庫進行查詢與各類操作時，SQL 語句中的參數應以變量形式傳輸給服務器，不應直接將參數的值拼接到SQL 語句的文本中。（二）參數的類型包括所有數據類型，而不僅是字符串類型。（3） 參數值的來源包括但不限于：用戶輸入的數據、從數據庫中讀出的數據、從配 置文件中讀出的數據、從外部系統中獲得的數據、其它程序邏輯計算得出的數據，等等。（4） SQL 語句的執行位置包括但不限于：代碼中的SQL 語句，數據庫的存儲過程、觸發器、定時器等。（五）應用程序在處理用戶非法URL 請求，觸發后臺應用程序的SQ

19、L 錯誤時，應返回 處理后的錯誤頁面提示，禁止直接拋出數據庫SQL 錯誤， 如出現 ORA-xxx 等等。資料4.2.15 頁面中的非源代碼內容應經過URI 編碼（一）頁面中的非源代碼內容，應該以URI 編碼后的字符出現，避免特殊字符直接出現在頁面中。（二） 內容的來源包括但不限于：在服務器端由程序生成的頁面內容、在瀏覽器端由腳本生成的頁面內容（如：javascript 中的 document.write 函數） 。（三）頁面中的隱藏內容、頁面格式控制等，也應受本條約束。4.2.16 頁面中拼裝的腳本應校驗元素來源的合法性（一）在瀏覽器端拼裝并運行（如：利用javascript 的 eval

20、函數執行）的腳本，應校驗拼裝元素的來源合法性，確定其中沒有危害性的內容。（二） 校驗的范圍包括但不限于：變量名元素應符合標識符的規則、整型元素只包含數字、元素中不包含特殊字符。4.2.17 頁面請求處理應校驗參數的最大長度（一） WEB 服務器在接受頁面請求時，應校驗參數的最大長度，截斷超出最大長度的范圍。4.2.18 登錄失敗信息錯誤提示應一致（一） WEB 服務器在接受用戶登錄請求時，不應區分登錄失敗的提示信息（如：用戶名不存在、密碼錯誤、密碼已過期等），應采用統一的失敗提示信息（如：錯誤的用戶名或密碼）。4.2.19 避免頁面上傳任意擴展名的文件（一） WEB 服務器在接受頁面上傳文件時

21、，應對文件名進行過濾，僅接受指定范圍的文件（如：圖片, .zip 文件等） ，同時，要修改上傳后的文件名，不應接受可能存在危險的文件（如：.jsp, .sh, .war, .jar 文件等） 。（二）如果出于業務的需要（如：網盤等）必須接受任意擴展名的文件，則應自動修改上傳文件的擴展名，并注意采用統一的無風險的擴展名命名規則。4.2.20 避免接受頁面中的主機磁盤路徑信息（一） WEB 服務器接受的頁面請求中的任何內容，不得作為主機磁盤路徑（包括相對路徑）處理，尤其不得在程序中提取磁盤上的目錄、文件的內容傳送到頁面。資料4.2.21 第三方產品的合法性（一）應選擇合法的第三方產品，在使用第三方

22、產品前，需要進行安全的評估和版本篩選。5 系統部署安全規范5.1 部署架構和安全下圖顯示了需在程序設計階段考慮的幾個程序部署問題。應用程序安全性主機安全性部署拓撲本地遠程應用程序層應用程序層資料網絡基礎結構安全路由器防火墻交換機在應用程序設計階段，應考慮我司安全策略和程序，以及部署應用程序的基礎結構。通常，目標環境是固定不變的， 應用程序的設計必須要反映這些限制條件。有時需要折衷考慮設計方案，例如，由于存在協議和端口限制，或是特定部署拓撲結構的要求。要在設計初期確定存在哪些限制條件，以避免日后在開發過程中出現意外；另外，應邀請網絡和基礎結構工作組的成員參與此過程。5.1.1 網絡基礎結構組件確

23、保您了解目標環境提供的網絡結構，并了解網絡的基本安全要求，如篩選規則、端口限制、支持的協議等等。確定防火墻和防火墻策略可能會如何影響應用程序的設計和部署。在面向Internet的應用程序和內部網絡之間可能存在防火墻將其隔開。也許還存在用于保護數據庫的其他防火墻。這些防火墻影響了可用的通信端口，因此會影響 Web服務器到遠程應用程序和數據庫服務器的身份驗證選項。例如，Windows 身份驗證需要附加端口。在設計階段，需要考慮允許哪些協議、端口和服務從外圍網絡中的Web 服務器訪問內部資源。 還應確定應用程序設計所需的協議和端口，并分析打開新端口或使用新協議會帶來哪些潛在威脅。交流并記錄所有有關網

24、絡和應用層安全的設想，以及哪些組件將處理哪些問題。這樣，當開發人員和網絡管理人員都認為對方會解決安全問題時，可以防止安全控制失敗。注意網絡為應用程序提供的安全防范措施。設想如果更改網絡設置，可能會帶來哪些安全隱患。如果實現特定的網絡結構更改，將會出現多少安全漏洞？5.1.2 部署拓撲結構應用程序的部署拓撲結構和是否具有遠程應用層是設計階段必須考慮的關鍵問題。如果具有遠程應用層，需要考慮怎樣保護服務器之間的網絡以減少網絡竊聽威脅，以及怎樣保護敏感數據的保密性和完整性。此外， 還要考慮標識符流，并確定在應用程序連接到遠程服務器時將用于網絡身份驗證的帳戶。 一種常見方法是使用最小特權進程帳戶，并在遠

25、程服務器上創建一個具有相同密碼的帳戶副本（鏡像）。另一種方法是使用域進程帳戶，此類帳戶管理方便，但會帶來更大的安全問題，因為很難限制該帳戶在網絡上的使用。未建立信任關系的介入防火墻和單獨域使應用本地帳戶成為唯一的選擇。5.2 部署操作安全規范5.2.1 確保管理界面的安全配置管理功能只能由經過授權的操作員和管理員訪問，這一點是非常重要的。關鍵一點是要在管理界面上實施強身份驗證，如使用證書。如果有可能，限制或避免使用遠程管理，并要求管理員在本地登錄。如果需要支持遠程管理， 應使用加密通道，如 SSL 或 VPN 技術， 因為通過管理界面傳遞的數據是敏感數據。此外，還要考慮使用IPSec 策略限制

26、對內部網絡計算機的遠程管理，以進一步降低風險。5.2.2 確保配置存儲的安全基于文本的配置文件、注冊表和數據庫是存儲應用程序配置數據的常用方法。如有可能，應避免在應用程序的Web 空間使用配置文件，以防止可能出現的服務器配置漏洞導致配置文件被下載。無論使用哪種方法，都應確保配置存儲訪問的安全，如使用 Windows ACL 或數據庫權限。還應避免以純文本形式存儲機密，如數據庫連接字符串或帳戶憑據。通過加密確保這些項目的安全，然后限制對包含加密數據的注冊表項、文件或表的訪問權限。5.2.3 單獨分配管理特權如果應用程序的配置管理功能所支持的功能性基于管理員角色而變化，則應考慮使用基于角色的授權策

27、略分別為每個角色授權。例如， 負責更新站點靜態內容的人員不必具有更改客戶信貸限額的權限。5.2.4 使用最少特權進程和服務帳戶應用程序配置的一個重要方面是用于運行Web 服務器進程的進程帳戶，以及用于訪問下游資源和系統的服務帳戶。應確保為這些帳戶設置最少特權。如果攻擊者設法控制一個進程， 則該進程標識對文件系統和其他系統資源應該具有極有限的訪問權限，以減少可能造成的危害。5.2.5 盡量避免存儲機密在軟件中以完全安全的方式存儲機密是不可能的。可以接觸到服務器的系統管理員可以訪問這些數據。例如， 當您所要做的僅僅是驗證用戶是否知道某個機密時，則沒有必要存儲該機密。在這種情況下，可以存儲代表機密的

28、哈希值，然后使用用戶提供的值計算哈希值，以驗證該用戶是否知道該機密。5.2.6 不要在代碼中存儲機密不要在代碼中對機密進行硬編碼。即使不將源代碼暴露在Web 服務器上，但從編譯過的可執行文件中仍然可以提取字符串常量。配置漏洞可能會允許攻擊者檢索可執行文件。5.2.7 不要以純文本形式存儲數據庫連接、密碼或密鑰避免以純文本形式存儲諸如數據庫連接字符串、密碼和密鑰之類的機密。使用加密，并存儲經過加密的字符串。5.2.8 限制主機上WEB 系統啟動用戶的權限（一）應將WEB 系統的啟動用戶的權限限制在最小范圍內，禁止該用戶訪問其它不必要的路徑（如：/etc/、 /root）。5.2.9 隱藏后臺調試

29、信息（一） WEB 系統、數據庫等報告的異常信息、調試信息不應該出現在頁面上。5.2.10 密碼加密存儲（1） WEB 系統中存儲的密碼應采用一定的加密算法，以密文形式存放。此處所指的密碼包括但不限于：1配置文件中的主機、網絡、數據庫、郵箱的密碼；2數據庫中的用戶資料密碼；（2） 加密算法的選擇應根據實際需要，首選不對稱加密算法，次選破解難度高的對稱加密算法。5.2.11 隱藏重要配置參數信息（一） 對于重要的配置參數信息，應采用必要的隱藏措施，具體技術請遵循我司敏感參數保護規范（二）此處所指的配置參數包括但不限于：1. 重要的用戶名、密碼；2. 重要設備的內網地址（如：數據庫、存儲設備）；5

30、.2.12 隱藏日志文件（一） 不應將日志文件的路徑設置在頁面可達的位置，用戶通過頁面應該無法訪問到系統產生的日志文件。5.2.13 禁用 WebDAV ，或者禁止不需要的HTTP 方法（一）在無特定的需求情況下，應只開放GET, HEAD, POST 等安全的HTTP 方法，禁用 PUT, DELETE, OPTIONS 等具有操作性質的HTTP 方法。5.2.14 保證管理平臺、測試賬號口令強度（一） WEB 系統的管理平臺、測試賬號的口令應具有足夠的強度。具體要求請遵循我司公司系統帳號口令管理辦法。5.2.15 定期核查文件上傳路徑、日志路徑中是否存在木馬（一）應定期對不可能出現代碼的路

31、徑進行檢查，及時發現與排除可能存在的木馬。（二）需要檢查的路徑包括但不限于：用戶文件上傳路徑、日志文件路徑。5.2.16 及時刪除應用系統臨時文件（一） WEB 系統中不應該含有不必要的文件。包括但不限于：.CVS 文件夾、.svn 文件夾、臨時備份文件等等。（二）對于WEB 頁面備份文件，不要以.bak 文件存放（如index.jsp.bak 等）5.2.17 重要系統隔離（一）在部署WEB 系統時，應根據實際情況，盡量使重要系統之間互相隔離、重要系統與其它系統之間隔離。（二）隔離措施包括但不限于：主機分離、數據庫分離、網段隔離。6 安全審計應該審核和記錄跨應用層的活動。使用日志，可以檢測到蹤跡可疑的活動。這通常能較早地發現成熟攻擊的跡象，日志還有助于解決抵賴問題，即用戶拒絕承認其行為的問題。在