WebSphere Application Server V7高級安全性增強，第2部分

高級安全性注意事項

簡介

第 1 部分 解釋了 IBM WebSphere Application Server V6.1 和更高版本在設計時如何考 慮到默認安全性安全原則。目標是在最多見的配置和比較簡單的環境中，讓這個產品在默認情 況下具備合理的安全水平，儘管這個目標尚未完美地實現。前一篇文章最後介紹了 WebSphere Application Server 中已經採用的許多重要的基於基礎設施的預防性安全措施。本 文介紹基於應用程序的其餘預防性措施，而後討論一些重要的注意事項。

儘管本文中的信息基於 IBM WebSphere Application Server V7，可是討論的大多數問題同 樣適用於 V6.1。對於某個版本特有的問題，咱們會專門指出。

基於應用程序的預防性措施

配置措施

到目前爲止，本文的重點是爲了建立安全的 IBM WebSphere Application Server 基礎設施 能夠採起的基本步驟。這顯然很重要，但僅僅關注基礎設施是不夠的。既然基礎設施已經增強 了，如今必須研究應用程序須要作哪些事情來確保安全性。固然，應用程序必須利用 WebSphere Application Server 提供的基礎設施，但應用程序開發人員還必須執行（或避免） 其餘一些操做以儘量提升應用程序的安全性。

不要將 Web 服務器的文檔根設置爲 WAR

仔細檢查每一個 servlet 別名是否安全

不要經過類名提供 servlet

不要將敏感信息放在 WAR 根目錄中

定義默認的錯誤處理程序

考慮禁用文件服務和目錄瀏覽

啓用會話安全性

注意定製的 JMX 網絡訪問

爲了幫助您將這些措施與特定的攻擊類別聯繫起來，每一個措施使用 第 1 部分 介紹的標記 表示攻擊的類別。

1. 不要將 Web 服務器的文檔根設置爲 WAR

WAR 文件包含應用程序代碼和大量敏感信息。其中只有一部分信息是能夠向 Web 提供的內 容。所以，將 Web 服務器文檔根設置爲 WAR 根目錄是不合適的。若是這樣作，Web 服務器將 不加解釋地提供 WAR 文件的全部內容。這會致使將代碼、未經處理的 JSP 和其餘內容提供給 最終用戶。（這個措施只在 Web 服務器和應用程序服務器放在一塊兒時纔有用。）

2. 仔細檢查每一個 servlet 別名是否安全

WebSphere Application Server 經過 URL 保護 servlet。每一個要保護的 URL 都必須在描 述應用程序的 web.xml 文件中指定。若是 servlet 有不止一個別名（也就是說，多個 URL 訪 問相同的 servlet 類），或者有許多 servlet，則很容易遺忘對某個別名的保護。這須要當心 。因爲 WebSphere Application Server 保護的是 URL，而不是底層類，因此即便只有一個 servlet URL 是不安全的，入侵者也可以繞過您的安全措施。爲了減小這種威脅，應該儘量 使用通配符來保護 servlet。若是那樣作不合適，則應該在部署前再次仔細檢查 web.xml 文件 。

APAR PK83258（在 WebSphere Application Server Versions 7.0.0.7 和 6.1.0.27 中） 會像對待 GET 請求那樣檢查 HEAD 請求的受權，所以在必定程度上堵住了這個漏洞。

在爲 servlet 指定受權約束時，要確保不列出任何方法，或者很是仔細地列出 servlet 的 全部方法（極可能在多個約束中），好比 GET、POST、PUT、HEAD 等。對於每一個 Java™ EE 規範，若是受權約束顯式地列出方法，沒有提到的方法就沒有受權約束！這對於 HEAD 等方 法尤爲危險，HEAD 在默認狀況下經過調用 GET 獲取所需的頭，這實際上會調用 GET 方法而不 檢查它的受權約束。清單 1 中的 web.xml 代碼是不安全的，而清單 2 中的代碼是安全的。

清單 1. web.xml – 不安全

　
　　myservlet
　　/myservlet
　　GET
　
　
　　arole

清單 2. web.xml – 安全

myservlet
/myservlet


arole

3. 不要經過類名提供 servlet

能夠經過類名或通常的 URL 別名來提供 servlet。 一般應用程序選用後者。也就是說，開發人員在 web.xml 文件中手動定義從每一個 URL 到每一個 servlet 類的準確映射，或者使用各類 WebSphere Application Server 開發工具之一來定義 。

然而，WebSphere Application Server 也容許經過類名提供 servlet。一個通用的 URL（例如 /servlet）並不爲每一個 servlet 定義映射，而是提供全部 servlet。假設基本路徑 後面的路徑成分是 servlet 的類名。例如，"/servlet/com.ibm.sample.MyServlet" 引用 servlet 類 "com.ibm.sample.MyServlet"。

經過類名提供 servlet 是經過在 ibm- web-ext.xmi 文件中將 serveServletsByClassnameEnabled 屬性設置爲 true 完成的，或者在 IBM Rational® Application Developer 的 WAR 編輯器中選中 serve servlets by classname。請不要啓用這個特性 —— Rational Application Developer 在默認 狀況下啓用它，因此您必須禁用它。這個特性使得知道 servlet 類名的任何人均可以直接調用 它。即便 servlet URL 是受保護的，攻擊者也可能繞過正常的基於 URL 的安全措施。另外， 根據類裝載器的結構，攻擊者可能可以調用您的 Web 應用程序以外的 servlet，好比 IBM 提 供的 servlet。

若是不肯定各個應用程序的設置是否錯誤地啓用了經過類名提供 servlet，能夠經過 設置一個定製屬性 讓應用程序服務器忽略這個設置，從而禁用經過類名提 供 servlet。

4. 不要將敏感信息放在 WAR 根目錄中

WAR 文件包含可提供的內容。Web 容器將提供 WAR 文件根目錄中的任何文件。只要只在根 目錄中放置應該提供的內容，就沒問題。所以，決不要將不該該顯示給最終用戶的內容放在 WAR 的根目錄中。例如，不要將屬性文件、類文件或其餘重要信息放在那裏。若是您必須將這 種信息放在 WAR 中，則將其放在 WEB-INF 目錄中，這是 servlet 規範容許的。Web 容器決不 會提供那裏的信息。

5. 定義默認的錯誤處理程序

當 Web 應用程序中出現錯誤時，即便是在應用程序分派以前（例如 WebSphere Application Server 沒法發現目標 servlet），會向用戶顯示錯誤消息。在默認狀況下， WebSphere Application Server 會顯示錯誤的原始異常堆棧轉儲。這不只對最終用戶很是不友 好，也暴露了應用程序的有關信息（堆棧信息中有類和方法的名稱）。同時還顯示異常消息， 其中可能包含敏感信息。

最好定義默認的錯誤頁面，每當出現未處理的異常時顯示它，從而確保最終用戶永遠看不到 原始錯誤消息。此頁面能夠是對用戶友好的錯誤消息，而不是堆棧跟蹤。默認的錯誤頁面是在 ibm-web-ext.xmi 中使用 defaultErrorPage 屬性定義的，也能夠在 Rational Application Developer 中使用 Web 部署描述符編輯器（Extensions 選項卡）設置。

6. 考慮禁用文件服務和目錄瀏覽

能夠經過禁用 Web 應用程序中的文件服務和目錄瀏覽，進一步限制提供不適當內容的風險 。固然，若是 WAR 包含可提供的靜態內容，則必須啓用文件服務。

7. 啓用會話安全性

WebSphere Application Server 一般不強制對 HTTP 會話訪問進行任何受權。任何具備有 效會話標識符的一方均可以訪問會話。雖然會話標識符不可猜想，但也可能經過其餘手段得到 會話標識符。

要想下降這種攻擊形式的風險，應該考慮啓用會話安全性。這一設置是在 Application server > > Web container > Session management 面板中配 置的。只需選擇 Security integration 選項，見圖 1。

圖 1. 會話安全完整性

WebSphere Application Server 將跟蹤哪一個用戶（根據用戶提供的 LTPA 憑證來肯定）擁 有哪一個會話，確保只有特定用戶才能訪問特定會話。

在極少數狀況下，這種設置會破壞 Web 應用程序。若是應用程序同時包含安全的（具備授 權約束）和不安全的 servlet，則不安全的 servlet 將沒法訪問會話對象。一旦一個安全的 servlet 訪問該會話，則它會被標記爲由該用戶 「擁有」。以匿名方式運行的不安全的 servlet 若是試圖訪問這些頁面，則會受權失敗。從 WebSphere Application Server V6.1 開 始，能夠更改受權行爲，確保沒有受權約束的 servlet 繼承當前用戶身份（若是已經有的話） ，這樣就解決了這個問題。圖 2 說明如何設置這個特性。

圖 2. 保留現有的身份

防止攻擊

啓用會話安全性實際上能夠防止一種攻擊。假設網站在用戶執行身份驗證並使用 HTTPS 之 前創建 HTTP 會話（大多數網站都是這樣）。在這種狀況下，會話 cookie (JSESSIONID) 是明 文的，攻擊者很容易捕獲它。以後，當用戶執行身份驗證時，固然應該切換到 SSL 並確保只通 過 SSL 傳輸 LTPA cookie。問題在於攻擊者已經獲得了 JSESSIONID cookie。根據編寫應用程 序的方式不一樣，攻擊者可能可以使用這個 cookie 和不一樣的 LTPA cookie（多是表明他本身 的身份的 cookie），做爲第一個用戶訪問應用程序。這是一種很是嚴重的攻擊，並且若是使用 開放的無線網絡，這很是容易實現。啓用會話安全性能夠阻止這種攻擊，由於應用服務器會阻 止訪問不禁當前用戶擁有的會話。

8. 注意定製的 JMX 網絡訪問

JMX 和定製的 MBean 讓應用程序可以支持強大的遠程定製管理。可是注意，JMX MBean 是 能夠經過網絡訪問的。若是選擇部署它們，要十分謹慎，要確保它們的操做具備合適的受權。 WebSphere Application Server 會根據 MBean JAR 文件中的描述符中的信息，自動爲 MBean 提供默認的受權限制。這樣是否合適取決於您的應用程序。更多信息請參閱 [was deploy]。

設計和實現措施

接下來，咱們將注意力轉移到應用程序開發人員和設計人員爲了構建安全的應用程序必須採 取的操做上。這些步驟是很關鍵的，但遺憾的是常常被忽視。

使用 WebSphere Application Server 安全性來保護應用程序

不要依賴於 HTTP 會話跟蹤用戶身份

保護應用程序的每一層

檢驗全部用戶輸入

編寫安全的應用程序

安全地存儲信息

不要審計和跟蹤敏感信息

避免對瀏覽器客戶機使用基自己份驗證

9. 使用 WebSphere Application Server 安全性來保護應用程序

應用程序開發團隊一般能認識到他們的應用程序須要某種程度的安全性。這一般是業務上的 需求。遺憾的是，許多團隊決定本身開發安全性基礎設施。這雖然也有可能作好，可是很是困 難，並且到頭來大部分團隊都不能成功。相反，他們的系統看似很安全，但實際上系統安全性 很是脆弱。安全性是個很困難的問題。密碼術的微妙問題、重播攻擊和各類形式的攻擊很容易 被忽視。這裏要說的是您應該使用 WebSphere Application Server 安全性。前面曾經建議您 啓用應用程序安全性；這裏建議在應用程序中實際使用它。

關於 Java EE 定義的聲明性安全模型，最多見的抱怨多是它沒有提供足夠的粒度。例如 ，只能在 EJB 或 servlet 的方法級上執行受權（在這個上下文中，servlet 上的方法是 HTTP 方法之一，好比 GET、POST、PUT 等等），而不能在實例級上執行受權。再如，全部的銀行帳 號都有相同的安全性限制，可是您但願某些用戶對他們本身的帳號擁有特殊權限。

這個問題能夠經過 Java EE 安全性 API isCallerInRole 和 getCallerPrincipal 來解決 。經過使用這些 API，應用程序能夠開發本身強大且靈活的受權規則，可是仍然要經過已知是 準確的信息來驅動這些規則：來自 WebSphere Application Server 運行時的安全性屬性。如 果這仍然不夠，能夠構建（或購買）更精細的受權框架，框架應該使用應用程序服務器已經維 護的現有安全信息（好比組）。即便這不夠，但安全基礎設施是高度可定製的。利用（並在需 要時擴展）現有的能夠正常工做的東西是正確的方法，而不該該拋棄現有的東西，嘗試從頭構 建安全基礎設施。

一個弱安全性的例子

能夠將 WebSphere Application Server 安全性基礎設施和其餘身份驗證或受權產品集成。 例如，IBM Tivoli Access Manager 能夠提供身份驗證和受權支持，IBM Tivoli Security Policy Manager 能夠提供更多受權功能。

這裏是一個弱安全性系統的例子。不使用 WebSphere Application Server 安全性的應用程 序傾向於建立本身的安全令牌，並在應用程序內部傳遞它們。這些令牌一般包含用戶名和一些 安全屬性，好比用戶的組成員身份。這些安全令牌經常沒有可經過密碼學技術驗證的信息。這 種方法假設能夠根據這些令牌中的信息作出安全性決策。這是錯誤的。這些令牌僅僅斷言用戶 的特權。這裏的問題是，任何 Java 程序都可以僞造這些安全對象，而後就能夠經過後門侵入 系統。最能說明這個問題的例子是，應用程序在 servlet 層建立這些令牌，而後將其傳遞到 EJB 層。若是 EJB 層不安全（請參見第 11 條），則入侵者可使用僞造的憑證直接調用 EJB ，使應用程序的安全性徹底失效。所以，除非完成細緻的工程工做，可靠的用戶信息來源只有 WebSphere Application Server 基礎設施。

10. 不要依賴於 HTTP 會話跟蹤用戶身份

許多本身實現安全性的應用程序經過使用 HTTP 會話來跟蹤用戶的身份驗證會話。這是很是 危險的。該會話是經過（URL 或者 cookie 中的）會話 ID 來跟蹤的。雖然該 ID 是隨機生成 的，可是它仍然可能遭受重播攻擊，由於它沒有具體的絕對超時時間。只有在一段時間內沒有 活動的狀況下，纔會發生超時 —— 若是截獲了會話 cookie，就可能在不受限制的時間段內濫 用該 cookie。另外一方面，當應用程序使用 WebSphere Application Server 安全性時會建立 LTPA 令牌，它是更強的身份驗證令牌。特別是，LTPA 令牌的生存期有限並使用強加密，安全 性子系統會對多是僞造的 LTPA 令牌的收據進行審計。

使用 HTTP 會話還有一個更危險、更微妙的安全性問題：會話 cookie (JSESSIONID) 經常 是在用戶執行身份驗證以前建立的 —— 一般在用戶第一次訪問站點時。此時，cookie 經常通 過 HTTP 做爲明文發送。用戶執行身份驗證以後，大多數應用程序會改用 HTTPS 傳輸之後的所 有通訊流以保護 cookie 和內容；可是，JSESSIONID cookie 可能已經被盜了，由於在最初通 過 HTTP 發送該 cookie 時攻擊者能夠捕獲它。除了儘量避免使用 HTTP 會話以外，經過啓 用會話安全性並把 LTPA cookie 限制爲 HTTPS，能夠下降 HTTP 會話被盜的風險。

11. 保護應用程序的每一層

咱們經常將 Web 應用程序以必定程度的安全性（自制的或者基於 WebSphere Application Server 的）部署在 servlet 層，可是對應用程序中的其餘層卻不加保護。這樣作是基於一個 錯誤的假設：應用程序中只有 servlet 須要保護，由於它們是應用程序的前門。可是，正如警 察常說的那樣，也必須鎖上您家的後門和窗戶。在許多場景中均可能出現這種疏忽，可是若是 Java 客戶機不是應用程序的一部分，而是在多層架構中使用可遠程訪問的組件（好比可經過 IIOP 或 Web 服務訪問的 EJB），則最容易出現這種狀況。在這種狀況下，開發人員經常認爲 可遠程調用的組件不須要保護，由於根據應用程序設計它們不是 「用戶能夠訪問的」，但這種 想法是一個危險的錯誤。若是不對服務層實施保護，入侵者就能夠繞過 servlet 接口，直接進 入服務層並進行破壞。

一般，對此問題的第一反應就是經過一些日常的手段來保護服務，好比將它們標記爲可由所 有已經過身份驗證的用戶訪問。可是，根據註冊表，「全部已經過身份驗證的用戶」 多是公 司中的每一個僱員。一些組織更進一步，把訪問權限制在某個組的成員，這個組指定 「能夠訪問 此應用程序的全部人」。這樣好一些，可是一般還不夠，由於可以訪問應用程序的每一個人並不是 都有必要執行應用程序中的全部操做。解決這個問題的正確方式是在服務中實現受權檢查。對 於 EJB，也能夠考慮將 EJB 組件實現爲只有本地接口，這樣就不可能遠程鏈接它們。

12. 檢驗全部用戶輸入

跨站點腳本是一種至關危險的攻擊，它利用了 Web 瀏覽器的靈活性和強大功能。大多數 Web 瀏覽器均可以解釋多種腳本語言，例如 JavaScript™。瀏覽器知道它要根據特殊的 轉義字符序列來尋找可執行的代碼。這是 Web 瀏覽器的強大之處，也是安全性模型中很危險的 漏洞。

入侵者能夠欺騙 Web 站點在瀏覽器中顯示入侵者但願該站點執行的腳本，經過這樣作來利 用此漏洞。在容許任意用戶輸入的站點上，這是很容易作到的。例如，若是站點包含一個用於 輸入地址的表單，用戶能夠在其中輸入 JavaScript。當站點隨後顯示該地址時，Web 瀏覽器就 會執行該腳本。該腳本因爲來自該站點並在 Web 瀏覽器內部運行，因此能夠訪問安全信息，例 如用戶的 cookie。

到此爲止，這還看似沒什麼危險，但入侵者能夠更進一步，他們 欺 騙用戶進入一個 Web 站點並輸入惡意腳本，欺騙手段能夠是經過電子郵件向用戶發送無害的 URL 或者把 URL 發佈在公共博客上。如今，入侵者就能夠在用戶的瀏覽器中運行任意代碼，通 常會訪問 cookie，他們能夠看到全部鍵盤活動和顯示的全部頁面。這樣，入侵者就能夠對此用 戶形成沒法挽回的損害。

這個問題其實是與用戶輸入檢驗相關的問題的一個特例。只 要容許用戶輸入任意文本，就必須確保該文本不包含會形成破壞的特殊字符。例如，若是用戶 要輸入一個字符串，用它來搜索某個索引，則必須過濾掉可能會形成越界搜索的不合適的通配 符，這是很重要的。對於跨站點腳本的預防，須要過濾掉瀏覽器支持的腳本語言的轉義字符。 這裏要說明的是，對全部外部輸入都應該採起懷疑態度並仔細進行檢驗。必須解決的問題很是 多，對它們的全面討論超出了本文的範圍。

13. 編寫安全的應用程序

鑑於本文的目標和篇幅，不可能在這裏列舉可能影響應用程序安全性的全部應用程序設計和 編程問題。若是對開發安全應用程序很感興趣，請參閱下面這些關於安全應用程序的設計、開 發和測試的參考資料：

圖書：Writing Secure Code

圖書：Software Security: Building Security In

OWASP，它發表瞭如下指南：

Development Guide

Code Review Guide

Testing Guide

Web Application Security Consortium

Penetration testing frameworks

另外，最近發表的一份 IBM 紅皮書 討論瞭如何使用 IBM Rational AppScan 做爲開發週期 的關鍵元素，從而構建安全的 Web 應用程序。

14. 安全地存儲信息

要建立安全的系統，必須考慮在哪裏存儲或顯示信息。有時，一些至關嚴重的安全性漏洞是 無心間形成的。例如，對在 HTTP Session 對象中存儲高度機密的信息要十分謹慎，由於此對 象可能被序列化到數據庫中，所以能夠從那裏讀取它。若是入侵者能夠訪問您的數據庫（甚至 是對數據庫捲進行原始計算機級訪問），他就可能看到會話中的信息。毫無疑問，這樣的攻擊 須要很是高的技能。

15. 不要審計和跟蹤敏感信息

出於業務目的和調試目的，任何比較複雜的應用程序都會生成豐富的日誌和跟蹤信息。這是 很好的。可是要記住，這些文件中的信息每每保存在許多地方（可能位於您的組織以外）。對 於很是敏感的信息，不該該進行跟蹤，若是能夠，也應該試圖避免對其進行審計。例如，咱們 見過客戶機將用戶的密碼、駕照號碼和社會保險號碼輸出到跟蹤文件中。若是該文件被不當的 人（多是幫助您的顧問）閱讀，就會暴露敏感信息。

爲了確保安全，應該限制並檢查日誌記錄的內容。

16. 避免對瀏覽器客戶機使用基自己份驗證

基自己份驗證的問題是 Web 瀏覽器會緩存用戶 ID 和密碼，在須要時會在之後的請求中自 動從新發送它。這意味着使用基自己份驗證的用戶不可能註銷。例如，若是用戶的 LTPA 令牌 過時了，應用程序服務器會再次詢問用戶 ID 和密碼。瀏覽器會從新發送它，因此超時就沒意 義了。更糟糕的是，若是之後經過 HTTP 發送請求（不加密），瀏覽器會經過網絡以明文形式 發送密碼。

當客戶機不是瀏覽器時，基自己份驗證是合理的方法。例如，Web 服務或 REST 客戶機經常 安全地使用基自己份驗證。固然，這種請求應該經過 SSL 發送。

高級注意事項

如今，咱們繼續討論一些與安全性增強相關的高級問題，包括跨計算單元信任、應用程序隔 離、身份傳播和 WebSphere Application Server 安全性中的限制。在大多數狀況下，這裏並 不提出具體的建議，而是提供一些重要的信息，幫助您維護和管理安全的基礎設施。

計算單元信任和隔離

WebSphere Application Server 計算單元不該跨越信任邊界。若是不能徹底信任某些人， 則不要讓他們管理您的計算單元或管理計算單元內的計算機。WebSphere Application Server 管理基礎設施不考慮細粒度的管理安全性，而是在整個計算單元範圍內每一個 WebSphere 進程之 間採起粗粒度的共享信任模型。每一個應用程序服務器都包含管理基礎設施，包括內部 API。在 積極的方面，這樣就消除了共同的控制和故障點，使得應用服務器具備很高的獨立性和穩定性 ，可是這也對隔離有負面影響。這種方法的影響包括：

WebSphere Application Server 計算單元中的每一個應用程序服務器都對整個計算單元具備 徹底的管理權限。若是任何應用程序服務器被攻破，則全部應用程序服務器都會被攻破。

物理計算機邊界（獨立的計算機、LPAR、節點等等）幾乎對計算單元安全性沒有任何影響。 計算單元中的信任單元是全部節點上的全部應用程序服務器。

進程邊界對計算單元安全性幾乎沒有影響。從安全的角度來看，將應用程序放在單獨的應用 程序服務器 JVM 中對加強計算單元內的隔離性並無太大用處。

單獨的操做系統標識對計算單元的安全性幾乎沒有影響。因爲應用程序服務器使用各類協議 與計算單元的其餘部分進行通訊，而這些協議不是由操做系統管理的，所以通常的操做系統保 護措施沒有效果。

這就引出了兩個關鍵主題：管理隔離和應用程序隔離。

管理隔離

對於 WebSphere Application Server，在默認狀況下全部管理員都對整個計算單元具備管 理權限（根據分配給他們的角色）。在 WebSphere Application Server V6.1 中增長了一個稱 爲受權組的新特性，所以能夠以更細的粒度（服務器、應用程序、節點、集羣等等）授予管理 權限。在 V6.1 中，受權組只由 wsadmin 支持。在 WebSphere Application Server V7 中， 管理控制檯也支持它們。若是您的計算單元很大，有許多管理員，則應該考慮使用這些功能。

應用程序隔離

在此上下文中，應用程序隔離基本上是關於如何防止一個應用程序的惡意操做對另外一個應用 程序形成損害。此類攻擊很難避免。現實狀況是，基礎設施軟件產品（好比 Java EE 應用程序 服務器）還沒有達到多用戶操做系統的成熟水平。它們沒法提供操做系統一般在多個用戶之間提 供的可靠隔離。

這會影響您嗎？

首先，也是最重要的，此處討論的缺陷都只是內部缺陷。只有安裝到計算單元中的應用程序 才能利用這些缺陷。根據 IBM 的經驗，絕大部分 WebSphere Application Server 用戶（甚至 包括使用共享基礎設施的用戶）都不受這些問題影響。這是由於他們認識到了其共享基礎設施 位於企業內部，運行的是獲得企業承認的代碼。所以，他們一般不要求應用程序實現徹底的安 全隔離。

受到此處的問題影響的 WebSphere Application Server 用戶一般具備很是嚴格的安全策略 ，例如：

具備正式的策略，要求應用程序不能訪問其餘應用程序的數據，即便它們在共享基礎設施中 運行。

對於早於 WebSphere Application Server 的系統，要求每一個應用程序在共享服務器上以單 獨的用戶 ID 運行，詳細地規定關於文件系統權限的規則，每一個應用程序都具備專用進程，並 嚴格執行對這些要求的審計過程。

具備嚴格的企業安全方針，嚴格執行以確保這些方針獲得了聽從，極可能包括應用程序架構 和代碼檢查。若是沒有代碼檢查，開發人員可能會插入違反企業策略的代碼。

它們也可能十分關注遠程攻擊，遠程攻擊可能在攻破了一個應用程序後，而後利用它來破壞 其餘應用程序。

若是您的環境沒有這些特色，那麼本節中的問題對您不適用，能夠 跳到下一節。

能夠採起何種緩解措施？

能夠採起如下緩解措施：

對全部應用程序代碼執行嚴格的代碼檢查。最好配合使用源代碼管理系統。這樣，對於每次 代碼更改會跟蹤進行更改的人員，並針對每次代碼更改安排和跟蹤代碼檢查。在這種狀況下， 單個程序員不可能將惡意代碼插入到您的系統中。相反，進行任何破壞都須要多人合做。咱們 認爲這至關重要，由於即便實現了應用程序隔離，惡意的應用程序代碼也很容易在單一應用程 序中形成嚴重的損害。

若是您選擇購買在 WebSphere Application Server 上運行的商業應用程序，請確保僅從可 靠的、值得信任的供應商處購買，要對應用程序進行細緻的測試和監視，而後再進行生產部署 ，並在生產環境中對其進行監視。

若是確實有必要，就將應用程序部署到私有的 WebSphere Application Server 計算單元中 。能夠考慮根據風險和信任程度，對不一樣的業務單位或其餘組織單位使用不一樣的計算單元。爲 了限制硬件成本，能夠在單一計算機或 LPAR 上安全地運行來自多個計算單元的節點。只需使 用不一樣的操做系統用戶 ID、不一樣的加密密鑰和不一樣的管理密碼運行每一個計算單元便可。從安全 性角度而言，這將提供徹底的隔離。

若是這些方法都不可接受，則能夠對基礎設施應用應用程序隔離增強技術。注意，這些技術 都要求作大量的工做。更重要的是，它們不能保證提供隔離。在同一個計算單元中的應用程序 （即便啓用了管理安全性、應用程序安全性和 Java 2 安全性）可能會訪問其餘應用程序的資 源或改變計算單元配置，從而損害同一計算單元中的其餘應用程序。沒法保證不會出現此類破 壞。

提出了這些警告以後，下面幾節繼續討論能夠顯著提升計算單元內的應用程序安全隔離的措 施。您可能很快發現這些措施很難實施，並且成本很高。更好、成本更低的方法是，經過嚴格 的僱員管理、代碼檢查和其餘管理控制機制，確保您的應用程序開發人員交付可信的代碼。與 前面同樣，按優先次序列出這些措施。

不要在 Java EE 資源上指定組件管理的別名

不要在資源上定義默認的用戶 ID 和密碼

Java 2 安全性

利用安全連鎖委託

保護 TAM WebSEAL TAI 密碼

注意定製 JMX 代碼中提高的權限

謹慎地使用 DynaCache

當心地使用全部資源

1. 不要在 Java EE 資源上指定組件管理的別名

在計算單元內運行的任何 Java EE 應用程序均可能訪問任何 Java EE 資源。這是由於資源 具備 JDNI 名稱，而任何應用程序均可以查詢此名稱，並且對於資源訪問沒有受權機制。所以 ，若是應用程序 A 要使用企業數據庫，只需將該數據庫定義爲數據源，則同一計算單元中的應 用程序 B 就能夠訪問此數據庫。

當應用程序試圖經過調用資源工廠（例如數據源或 JMS 鏈接工廠）上的 getConnection() 來訪問資源時，若是相應的底層資源可用，WebSphere Application Server 將隱式地向底層資 源提供身份驗證信息。提供何種身份驗證信息取決於身份驗證模式和可用的 J2C 身份驗證別名 。具體的細節很是複雜，但簡單來講，任何應用程序均可以查找 JNDI 名稱空間中的任何資源 。完成此工做後，將隱式地使用 「應用程序」 的身份驗證模式。這又意味着 WebSphere Application Server 將使用組件管理的身份驗證別名（若是有的話）。所以，計算單元中的任 何應用程序均可以訪問任何使用組件管理的別名定義的資源。注意，在不一樣的範圍內定義資源 對安全性並無影響。資源範圍僅僅是方便管理的機制。

另外一方面，若是隻在資源上定義容器管理的別名（或者不指定別名），惡意應用程序就不能 訪問此資源，由於當在全局 JNDI 名稱空間中查找資源時，將使用應用程序身份驗證，所以會 使用組件管理的別名。由於沒有組件管理的別名，因此沒法完成隱式身份驗證。

若是您選擇採用此方法，顯然仍然但願恰當的應用程序可以訪問這些資源。爲此，這些應用 程序必須在其部署描述符中指定用於訪問資源的本地資源引用。而後能夠在部署時將這些引用 綁定到正確的資源。若是應用程序在引用上指定了容器管理的身份驗證，則將隱式地使用在資 源自己上定義的容器管理的別名。這種狀況可使用一張圖加以說明。圖 3 顯示 IBM Rational Application Developer 引用編輯器，其中在一個 JMS 鏈接引用上指定容器管理的 身份驗證。

圖 3. 使用容器管理的身份驗證的數據庫資源引用

這種方法有兩個問題。首先，在 WebSphere Application Server V6.1 中，容器管理的別 名已經被錯誤地否決了（可是在 V7 中再也不是否決的）。其次，也是更重要的，您可能已經注 意到，並不是全部的資源都容許指定容器管理的別名（例如 V6.1 中的 JMS 工廠）。在這種狀況 下，必定不要在資源上提供默認身份驗證信息。必須在應用程序中爲每一個資源引用指定身份驗 證信息（在這裏身份驗證方法並不重要），好比在部署期間。此工做很是單調乏味，可是能夠 使用 wsadmin 自動執行。至少對於 MDB，能夠在激活規範中指定身份驗證信息。

XA 恢復別名不是問題

不要將組件管理的別名與資源上指定的 XA 恢復別名相混淆。XA 恢復別名僅在涉及到事務 故障的某些恢復場景中使用。若是啓用 Java 2 安全性並使用默認權限，則應用程序一般沒法 訪問該別名。

2. 不要在資源上定義默認的用戶 ID 和密碼

前一條的一個推論是，不該在資源上定義默認的用戶 ID 和密碼。若是這樣作，計算單元內 的任何應用程序就均可以查找該資源，而後隱式地使用提供的用戶 ID 和密碼。

3. Java 2 安全性

正如在前面討論的，全部應用程序服務器均包含 WebSphere Application Server 管理基礎 設施，於是也包含用於執行大部分管理操做的 API。學習了這些 API 的應用程序員能夠編寫調 用其中任何 API 的應用程序，於是實質上能夠執行任何管理操做。此外，文件系統配置存儲庫 包含大量敏感信息（如密碼）。任何應用程序均可以使用普通 Java I/O 來讀取這些文件。

WebSphere Application Server 包含對標準 JDK 提供的 Java 2 安全性的支持。IBM 已經 加強了 Java 2 支持，從而實施 Java EE 規範和保護 WebSphere Application Server 內部 API 不被非受權訪問。只需啓用 Java 2 安全性，就會自動地實施這些規則。所以，經過啓用 Java 2 安全性，就可爲運行時添加不少額外的保護，防止非法應用程序訪問。可是，若是不通 過正式的過程檢查授予的權限，使用 Java 2 安全性就沒什麼價值 —— 實際上，若是啓用它 而不檢驗策略文件，會讓狀況變得更糟糕，由於安全性並未提升，而應用程序開發更困難了， 性能也會略微下降。

一旦啓用了 Java 2 安全性，在默認狀況下，應用程序就被限制爲僅使用很小的 「安全的 」 權限集。若是應用程序須要更多的權限，它一般必須在 EAR 內包含的 was.policy 文件中 定義這些權限。應用程序在運行時會讀取 was.policy 文件，並將這些權限添加到標準集中。 顯然，這是一個潛在的安全漏洞。爲了讓這種機制正常發揮做用，須要經過嚴格的、定義良好 的過程決定、檢查和實施每一個應用程序的 Java 2 權限。若是任何應用程序試圖請求不可接受 的權限（即便在處理緊急狀況期間），就拒絕它。應該有一個正式的過程，其中包含判斷容許 應用程序具備哪些權限的安全檢查。即便有正式的過程，啓用 Java 2 安全性也應該很慎重； 除了須要多作一些工做以外，強制啓用 Java 2 安全性經常致使使用不適當的策略文件，爲實 現部署，這些策略文件每每不多提供有意義的保護。這不但要多作一些工做，還會產生虛假的 安全性。

安裝時的檢查和檢驗過程可能會十分單調乏味。不過，能夠採用另外一種方法。首先，對於很 多環境而言，大部分應用程序都須要一個公共附加權限集。若是能夠這樣作，基礎設施團隊可 以在節點上的 app.policy 文件中爲全部應用程序設置默認權限。只有須要不經常使用的權限的應 用程序才須要將所需權限放置在 was.policy 中並須要進行額外的檢驗。甚至能夠進一步進行 限制，禁止使用 was.policy 並要求由管理團隊將全部權限添加到 app.policy 中。這在某種 程度上會使得部署變得複雜（須要編輯一個公共文件），但能夠減小應用程序得到不恰當權限 的風險。

4. 利用安全連鎖委託

應用程序服務器的好處之一就是，會自動在系統層之間和跨應用程序發送用戶身份信息。這 樣就實現了透明的單點登陸 (SSO)。不過，這有一個可能很是危險的反作用：不恰當模擬。

此處的問題是，當用戶爲了使用應用程序 A 而進行身份驗證時，應用程序 A 可能對應用程 序 B 進行遠程 EJB 調用。這樣，應用程序 B 就會看到原用戶的憑證。一般，這沒有什麼問題 。可是，若是應用程序 A 不可信呢？在這種狀況下，訪問應用程序 A 的用戶就有理由擔憂它 會經過模仿以此用戶的名義訪問應用程序 B。設想一下，假如應用程序 A 「不重要」，所以是 採用臨時拼湊的方式開發的；而應用程序 B 是管理機密信息的高度敏感的應用程序。此處的問 題是，由於應用程序 B 與應用程序 A 共享一個公共安全域，所以必須信任應用程序 A。這非 常很差。

有一個辦法能夠解決此問題。可使用 WebSphere Application Server 中的一個特性，此 特性被大體描述爲 「安全連鎖委託」。經過使用 WSSecurityHelper.getCallerList() 或 getServerList()，應用程序 B 能夠肯定請求通過了哪些應用程序和服務器。若是應用程序 B 是高度敏感的應用程序，它可能要求該列表爲空，這表示它由用戶直接使用。關於 WSSecurityHelper 的更多信息請參閱 WebSphere Application Server 信息中心。

5. 保護 TAM WebSEAL TAI 密碼

當在 Tivoli Access Manager WebSEAL 和 WebSphere Application Server 之間配置了 SSO 時，WebSEAL 會在每一個請求的 HTTP 頭中發送其保密密碼，以確保 TAI 在調用時能正常工 做。雖然因爲鏈接應該使用 SSL 進行加密，因此一般這不是什麼問題，但這樣的確會向 WebSphere Application Server 中運行的 Web 應用程序公開 WebSEAL 密碼。（儘管本節專門 討論 WebSEAL TAI，可是經過發送密碼來創建信任的任何 TAI 都會發生這種狀況。）

若是運行在 WebSphere Application Server 中的某個 Web 應用程序不可信，它可能會獲 取此密碼，而後打開到某個應用程序服務器的 HTTP 鏈接並斷言任何用戶的身份。這樣，精心 編寫的惡意應用程序就可能冒充任何人進行操做了。

若是擔憂這種類型的攻擊（能夠經過代碼檢查輕鬆地防止），則能夠阻止任何不可信的客戶 機鏈接到 Web 容器。爲此，只需在 Web 容器上配置一個相互身份驗證的 HTTPS 監聽器便可， 請參閱 第 1 部分 中的說明。這樣，惡意應用程序就不能打開到 Web 容器的 HTTPS 鏈接了， 由於它們沒有正確的私鑰（只有 WebSEAL 或 Web 服務器擁有此私鑰）。

6. 注意定製 JMX 代碼中提高的權限

對於 Mbean，須要注意一點：要想使用它們，就須要提高 Java 2 安全性權限。若是應用程 序以編程方式嚮應用服務器運行時註冊 Mbean，那麼必須向發出調用的代碼授予提高的管理權 限。這種權限可用來執行非法管理操做。進行此操做時需格外當心。一種不錯的方法是建立一 個專門用於註冊 Mbean 的單獨模塊，並僅授予此模塊所需的權限。

第二種裝載 MBean 的方法是以管理方式將其指定爲 Extension Mbean（這是推薦的方法） 。這樣就消除了必須顯式地授予應用程序代碼管理權限的問題，可是又出現了一個新問題： MBean 如今由至關低層的 WebSphere Application Server 類裝載器進行裝載，此裝載器的信 任度更高。所以，與採用普通用戶代碼相比，MBean 將具備更多訪問 WebSphere Application Server API 的權限。

若是選擇開發定製的 Mbean，必須仔細地對代碼及其使用狀況進行檢查，以確保不會給系統 帶來安全漏洞。

7. 謹慎地使用 DynaCache

DynaCache 爲 WebSphere Application Server 應用程序提供分佈式共享緩存。不過， DynaCache 上並無訪問控制機制；在應用程序服務器中運行的任何應用程序均可以訪問此應 用服務器具備訪問權限的任何緩存。更準確地說，任何應用程序均可以訪問服務器可以訪問的 任何緩存，能夠看到（或修改）其全部內容。

有兩種緩存須要考慮。應用程序服務器自己維護一些隱藏的內部緩存（servlet 緩存、Web 服務緩存、安全緩存），其中可能包含敏感信息。還有用戶建立的緩存，好比能夠經過 JNDI 訪問的 Object Cache。

內部緩存並不在 JNDI 中註冊，因此更難找到它們，可是能夠經過使用內部 API 訪問它們 。從積極的方面來看，在默認狀況下這些緩存只複製到同一集羣中的服務器，因此能夠確信不 同集羣中的應用程序沒法看到其餘集羣的緩存內容。

用戶定義的緩存能夠在 JNDI 中看到，能夠在同一計算單元中的任何服務器上查找它們。查 找到緩存以後，應用程序就能夠修改或讀取緩存。沒法防止這種行爲。所以，若是關心應用程 序隔離，就不要使用用戶建立的緩存。

8. 當心地使用全部資源

不少其餘 WebSphere Application Server 資源（如工做區）並不提供應用程序級的受權。 與 DynaCache 同樣，您須要當心地使用這些資源。若是關心應用程序隔離，則應仔細地對每一個 使用場景進行評估，查找潛在的漏洞並採起相應措施。

跨計算單元的信任

一般，WebSphere Application Server 計算單元並不彼此信任，所以不可能實現跨計算單 元的 SSO。不過，能夠對計算單元進行配置，使其支持跨計算單元 SSO。這麼作有充足的理由 ，可是在這麼作時，其實是在擴展計算單元的信任域，須要注意對安全的潛在影響。須要考 慮三個問題：

一般，域就是一個註冊表。WebSphere Application Server V6.0.2 和更高版本放寬了這個 規則，能夠獨立於註冊表指定域名稱。

共享 LTPA 密鑰

要想讓兩個計算單元透明地參與 SSO 域，它們必須共享兼容的域（在 WebSphere Application Server V6.1 中這意味着同一個域，在 V7 中意味着可信域）、共享相同的 LTPA 加密密鑰並使用兼容的 SSL keyring（供服務器用於服務器通訊）。兼容的 SSL keyring 意味 着，與任何 SSL 通訊同樣，發出調用的服務器必須可以訪問與接收調用的服務器的證書對應的 簽名證書。

一旦確保兩個計算單元共享相同的 LTPA 加密密鑰，就建立了一個特殊的環境，此環境中的 每一個計算單元均可覺得其餘計算單元建立憑證，包括管理憑證。所以，若是一個計算單元被攻 破，則兩個計算單元都會被攻破。若是使用多個計算單元，因爲安全緣由須要實現應用程序隔 離，則須要啓用 Java 2 安全性來限制對 WebSphere Application Server 內部 API 的訪問。

若是共享相同的 LTPA 加密密鑰只是爲了建立 Web SSO，而不須要共享定製的主題，能夠通 過使用身份驗證代理服務器（好比 Tivoli Access Manager WebSEAL）實現相同的結果，而不 必共享 LTPA 加密密鑰。

CSIv2 身份斷言

若是要進行跨計算單元的 IIOP 調用，但但願避免共享 LTPA 加密密鑰，則徹底能夠實現。 爲此，必須使用 CSIv2 身份斷言（當與非 WebSphere Application Server EJB 服務器進行聯 系時，這也有用）。

讓咱們考慮一個簡單的場景：假定有兩個計算單元（A 和 B），它們均包含多個服務器。假 定計算單元 A 中的服務器須要對計算單元 B 中的服務器進行 RMI/IIOP 調用，但不會進行相 反的調用。爲了實現此功能，要配置 CSIv2 身份斷言。計算單元 A 中的服務器將向計算單元 B 中的服務器斷言身份。這裏不描述如何配置 CSIv2 身份斷言，只討論這樣作的影響。

爲了讓計算單元 B 中的服務器接受身份斷言，計算單元 A 中的上游服務器必須首先對自身 進行身份驗證。能夠採用兩種方式來對 CSIv2 進行此操做：基自己份驗證（上游服務器發送其 用戶 ID 和密碼）和客戶機證書身份驗證（上游服務器使用本身的證書進行身份驗證）。

身份驗證完成以後，接受調用的服務器將檢驗上游服務器是否可信，是否能夠執行身份斷言 。這是在 CSIv2 配置面板中配置的。此後，上游服務器向下遊服務器發送目標用戶的身份信息 。

讓咱們考慮一下此方法的信任影響。計算單元 B 中的服務器接受來自計算單元 A 的身份斷 言，所以信任計算單元 A。若是計算單元 A 被攻破，則計算單元 B 也會被攻破，但對於計算 單元 A 有何影響呢？

若是計算單元 A 發送服務器用戶 ID 和密碼來創建信任（這是默認行爲），這會讓計算單 元 B 中的服務器知道其服務器用戶 ID 和密碼，而此用戶 ID 具備徹底的管理權限。所以，計 算單元 A 如今徹底信任計算單元 B。與只共享 LTPA 密鑰相比，這並未提升安全性。

若是計算單元 A 發送一個指定的用戶 ID 和密碼（此 ID 只用於此用途），就不會向計算 單元 B 公開重要的信息。計算單元 A 不信任計算單元 B。

若是計算單元 A 使用本身的證書進行身份驗證，則不會向計算單元 B 公開任何內容。計算 單元 A 不信任計算單元 B。

總之，爲了讓計算單元 A 對計算單元 B 斷言身份，計算單元 B 必須信任計算單元 A。這 很是明顯。若是不但願計算單元 A 信任計算單元 B，則應該在服務器到服務器身份驗證步驟中 使用指定的用戶 ID 和密碼或證書身份驗證，而不是使用默認的方式（發送服務器 ID 和密碼 ）。

主題傳播回調

若是要使用跨計算單元 主題傳播，則必須注意計算單元還可能相互進行帶外調用來獲取主 題。爲了說明這一點，咱們來考慮一個例子：假定有兩個服務器共享一個 SSO 域。某個用戶使 用 Web 瀏覽器訪問服務器 A 並得到了一個身份驗證會話（在瀏覽器中由 LTPA cookie 表示） 。該用戶隨後訪問服務器 B。服務器 B 將試圖從服務器 A 獲取該用戶的主題。這稱爲主題傳 播。若是這些服務器位於相同的 DynaCache 複製域中，則很容易完成此操做。若是它們不位於 相同的域中，則使用 JMX 回調來獲取主題。固然，不一樣計算單元中的服務器不處於相同的 DynaCache 複製域中。所以，在這個示例中，服務器 B 將對服務器 A 進行安全 JMX 調用，以 獲取用戶的主題。

與任何管理調用同樣，JMX 調用須要進行身份驗證和受權。在這種狀況下（從 WebSphere Application Server V6.1 開始），經過使用共享的 LTPA 密鑰隱式地創建信任。由於服務器 B 與服務器 A 共享 LTPA 加密密鑰，因此服務器 A 信任它，會提供主題信息。

總而言之，除了因爲共享 LTPA 密鑰已經引入的風險以外，回調並不會顯著影響安全性，但 是它們引入了另外一個網絡路徑，一些人可能認爲這是風險。

這並不適用於出現使用 IIOP 的下游傳播時。在這種狀況下，上游服務器會直接將主題發送 到下游服務器。不須要進行 JMX 回調。

身份傳播

雖然此主題與安全性增強並不直接相關，但它是一個在系統設計中常常出 現且沒有儘早考慮安全性的問題。必須始終很是謹慎地對在何處創建身份以及如何傳播身份（ 若是能夠傳播）進行跟蹤。咱們見過不少設計直接假設身份是已知的，而實際技術卻使這不可 行。要確保對應用程序中的身份流進行仔細的分析，以防止在後面的開發週期形成大麻煩。下 面給出涉及到外部資源和解決方案（對於 WebSphere Application Server V6 和更高版本）的 兩種常見狀況。

數據庫與 WebSphere Application Server 身份驗證

企業系統 的主要挑戰之一就是恰當地實現強大的系統安全控制。簡單來講，須要用恰當的受權保護關鍵 數據。對於多層 Java EE 系統（其中的 Java EE 應用程序代碼會訪問數據庫，好比使用 JDBC 、SQLJ、JPA 或 CMP bean）來講，這個挑戰尤爲難以解決，由於用戶的身份信息一般會丟失。 這裏的 「用戶」 指的是應用程序表明其進行操做的用戶；也就是說，若是 Bob 使 用標準 Java EE 安全性向應用程序進行身份驗證，則 Bob 就是用戶。

在典型的基於 Java EE 的系統中，容器維護一個通過身份驗證的鏈接池。每一個用戶都會通過應用程序服務器 的身份驗證（使用幾種 Java EE 身份驗證機制之一），但用戶的身份信息對數據庫不可用。這 是由於全部數據庫訪問都是使用鏈接池中的公共共享鏈接之一執行的。在過去，這致使應用程 序不得不在應用層內從新實現現有的數據庫級受權和審計功能。即便處理得當，這也會浪費資 源，而處理不得當時，則極可能很是不安全。

在 WebSphere Application Server V6 中，對此問題有一個 精緻的解決方案。V6.1 中提供了把身份傳播到 IBM DB2® 的機制。

MDB 不以排隊者的身份運行

當消息在消息傳遞系統中排隊時，原始調用者的身份一般並不會與其相關。也就是說，消息 傳遞引擎根據前面討論的鏈接身份受權對隊列的訪問。隊列一般甚至不會記錄最終用戶的身份 。

當消息離開隊列時（在 Java EE 中一般由 MDB 將消息從隊列取出），原始調用者的身份不 可用 —— 即便此信息可用，也會被忽略。MDB 以匿名 Java EE 身份或靜態 run-as 身份運行 。它們不會以消息排隊者的身份執行。

在 WebSphere Application Server 中沒有用於處理此問題的直接支持。不過，若是您願意 編寫一些定製的代碼，就能夠解決此問題。從 WebSphere Application Server V6.0.2 開始， WebSphere Application Server 支持服務器端身份斷言。也就是說，服務器端代碼可使用 JAAS 更改其 Java EE run-as 身份，不須要提供密碼。它直接斷言用戶身份信息。下面是一個 使用 Java 代碼實現此功能的簡單示例：

清單 3

CallbackHandler　wscbh　=
　 WSCallbackHandlerFactory.getInstance().getCallbackHandler(username,　 null);
LoginContext　lc　=　new　LoginContext("system.RMI_INBOUND",　wscbh);
lc.login();

注意，這裏沒有提供密碼。

這能夠與 關於高級身份驗證的這篇文章 中的思想相結合以斷言定製的主題。按照 這篇信 息中心文章 中的描述，還可讓 WebSphere Application Server 建立 LTPA cookie，讓 Web 應用程序可以實現這個功能。

很明顯，這存在嚴重的安全隱患，所以在使用 Java 2 安全性時在默認狀況下這個調用被阻 止。可是，經過嚮應用程序代碼授予所需的 Java 2 安全權限，就可使用它。

WebSphere Application Server 限制

通常來講，經過仔細地進行配置，可使用 WebSphere Application Server 建立高度安全 的健壯的環境。不過應該注意，一些一般很小的、不太明顯的限制可能會對您有所影響。

目標身份未經檢驗

安全系統的一個很是微妙的方面是檢驗請求目標的概念。一般，當提到身份驗證時，咱們會 想到服務器驗證客戶機的身份，但客戶機如何驗證服務器的身份呢？客戶機如何知道服務器確 實是它所指望鏈接的服務器呢？大部分人都沒有認識到這一點，但 Web 瀏覽器天天都會隱式地 執行此項檢查。當使用 HTTPS 時，Web 瀏覽器將檢驗 Web 服務器的主機名是否與其證書中的 Web 服務器的主題相同。這能夠確保服務器確實是用戶所但願鏈接的服務器（固然，假定用戶 知道他們使用的主機名；不少人並不這樣細心）。

不太明顯的是，Web 瀏覽器執行的此項檢查並非 SSL 的固有部分，而是在 SSL 以外執行 的特定於瀏覽器的檢查。發起方（發出調用的服務器）必須明確地對證書執行此檢查。 WebSphere Application Server 並不執行此檢查。所以，當應用程序服務器（或客戶機）打開 到服務器的 SSL 鏈接時，它並不能確信該服務器就是但願使用的服務器。儘管可能性很小，但 是若是黑客能夠攻破您的內部 DNS 或網絡，就能夠在 WebSphere Application Server 計算單 元中插入一個欺詐服務器並竊取信息。這是一種異常困難的攻擊（不少其餘攻擊要簡單得多） ，但應當注意有這種可能性。

能夠從應用程序服務器信任存儲文件中刪除任何不須要的簽名密鑰，以防止出現這種狀況。 只有使用可信的簽署者頒發的證書才能發起這種攻擊。在 SSL 握手期間，客戶機將拒絕沒法檢 驗的服務器端證書。若是可信列表很小（或許僅包含自簽名證書），則發起此類攻擊會很是困 難。由於信任存儲在默認狀況下不包含任何 CA 簽署者，要關注的默認簽署者只有用於提供向 後兼容性的僞簽名證書。若是在共享的計算單元信任存儲中添加 CA 簽名證書，就會遇到這種 風險（儘管風險不大）。

保護桌面開發環境

在考慮安全性增強時，大多數人習慣於將注意力集中在生產系統上，生產系統天然是最重要 的。不過，您也應該花一些時間來確保其餘計算機（包括桌面系統）也具備合理的安全性。

對於這些運行 Rational Application Developer（或早期的 WebSphere Studio）的計算機 ，這是一個很是重要的問題。桌面 IDE 包含一個功能齊全的嵌入式 WebSphere Application Server 運行時環境。此應用程序服務器具備開放的端口，易於受到本文前面描述的各類方式的 遠程訪問攻擊。須要對此進行保護。

增強嵌入式應用程序服務器

至少應該在嵌入式應用程序服務器測試環境中啓用管理安全性。Rational Application Developer 7.5 在默認狀況下已經啓用了管理安全性。這能夠防止最嚴重的攻擊類型，其中入 侵者可能使用內置的管理基礎設施將惡意應用程序部署到您的桌面上。若是使用管理權限來運 行 Rational Application Developer，這就至關重要。您還可能但願採起本文中提到的其餘加 強步驟，不過確保管理基礎設施的安全是最爲重要的步驟。

增強嵌入式應用程序服務器的另外一種方法是安裝桌面防火牆產品，以阻止對您計算機的訪問 。若是配置得當，此方法會很是有效。信任整個內部企業網絡的防火牆在此場景中幾乎沒有價 值。

從之前的版本遷移

在 WebSphere Application Server 的不一樣版本之間遷移可能致使向後兼容性問題。從安全 性的角度來看，推薦的應用程序遷移方法是從頭構建一個完整的新計算單元，而後在新的計算 單元中安裝應用程序（固然先要進行嚴格的測試）。經過採用這種方法，就能夠受益於新版本 的全部默認配置更改。

若是使用 WebSphere Application Server 計算單元遷移工具，它們會把現有的配置和應用 程序複製到新的計算單元，所以不會受益於每一個主要版本對安全性的許多改進。這是由於咱們 會盡量少修改現有的配置，以便確保應用程序可以繼續正常運行。這麼作的反作用是增強默 認安全性的配置更改不會生效。所以，若是使用工具從 WebSphere Application Server V6 遷 移到 V7，就應該閱讀本文的 V6 和 V7 版本，而不僅是最新版本。

結束語

這篇由兩部分組成的文章討論了大量內容。雖然咱們討論了有關安全性的不少方面，可是重 點放在增強 WebSphere Application Server 環境這一核心主題上。但願您已經得到了保證 Java EE 系統安全所需的基本信息。本文的內容並不全面，您應當從其餘信息源查找關於增強 基礎設施的其餘部分的信息。WebSphere Application Server 只是冰山的一角。

可使用一個稱爲 IBM Security Scanner for WebSphere Application Server 的自動化 工具對本文中所描述的一部分事項進行檢查，能夠 下載 這個工具。

最後，若是但願進一步瞭解 WebSphere Application Server 安全性，請聯繫 IBM Software Services for WebSphere，參加關於 WebSphere Application Server 安全性的定製 的現場課程。這個課程深刻講解安全性增強、定製身份驗證、集成、單點登陸和各類其餘相關 主題。