程式師世界 >> 編程語言 >> 更多編程語言 >> WebSphere >> WebSphere Application Server V7高級安全性加強，第2部分

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

編輯：WebSphere

高級安全性注意事項

簡介

第 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 – 不安全

<security-constraint> 　 <web-resource-collection> 　　<web-resource- name>myservlet</web-resource-name> 　　<url- pattern>/myservlet</url-pattern> 　　<http-method>GET</http -method> 　</web-resource-collection> 　<auth- constraint> 　　<role-name>arole</role-name> 　</auth- constraint> </security-constraint>　

清單 2. web.xml – 安全

<security-constraint> <web-resource- collection> <web-resource-name>myservlet</web-resource-name> <url-pattern>/myservlet</url-pattern> </web-resource- collection> <auth-constraint> <role-name>arole</role- name> </auth-constraint> </security-constraint>　

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 > <server name> > 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 安全性的定制的現場課程。這個課程深入講解安全性加強、定制身份驗證、集成、單點登錄和各種其他相關主題。

WebSphere