kingpub

構建安全的 Web Services

本模塊內容

越來越多的公司和組織開始創(chuàng)建和部署 Web Services。通常，這些工作是在還未完全了解安全含義的情況下進行的。本模塊解釋了如何安全地設計、配置和部署 Web Services。對于任何接受外部請求的應用程序來說，輸入驗證十分重要，為此人們開發(fā)了幾種技術來確保只接受格式正確的請求。本模塊還詳細解釋了各種身份驗證方法，這些方法可以用來將 Web Services 訪問權僅限于授權用戶，并確保記錄和審核這些用戶的行為。

本模塊還討論了 Microsoft 的 Web Services Enhancements 1.0 for Microsoft? .NET (WSE)，它支持 WS-Security（Web Services 安全）和一組相關的最新標準。

返回頁首

目標

使用本模塊可以實現(xiàn)：

返回頁首

適用范圍

本模塊適用于下列產(chǎn)品和技術：

返回頁首

如何使用本模塊

為了充分理解本模塊內容，請：

返回頁首

概述

越來越多的公司使用 Web Services 通過 Internet 和企業(yè) Extranet 向客戶和商業(yè)伙伴提供產(chǎn)品和服務。這些服務提供商所需的安全要求非常高。在某些情況下（主要是在 Intranet 或 Extranet 情況下，在這兩種情況下，您對兩個終結點都有一定程度的控制權），可以使用操作系統(tǒng)和 Internet 信息服務 (IIS) 所提供的基于平臺的安全服務來提供點對點的安全解決方案。然而，基于消息的 Web Services 體系結構和日益增加的跨信任邊界的異構環(huán)境帶來了新的挑戰(zhàn)。這些情況需要在消息級別上解決安全問題，以支持跨平臺的互操作性和通過多個中間節(jié)點進行路由。

Web Services 安全 (WS-Security) 是用來解決這些問題的最新安全標準。Microsoft 已經(jīng)發(fā)布了 Web Services Enhancements 1.0 for Microsoft .NET (WSE)，以支持 WS-Security 和一組相關的最新標準。WSE 允許實施消息級別的安全解決方案，包括身份驗證、加密和數(shù)字簽名。

注意：WSE 支持的規(guī)范和標準是不斷變化的，因此當前的 WSE 并不保證與該產(chǎn)品將來的版本兼容。在寫本文時，互操作性測試正在進行，使用的是由包括 IBM 和 VeriSign 在內的供應商所提供的非 Microsoft 工具包。

返回頁首

威脅與對策

要構建安全的 Web Services，需要了解相關的威脅。Web Services 面對的主要威脅是：

圖 12.1 顯示了 Web Services 面對的主要威脅和攻擊。

圖 12.1
主要的 Web Services 威脅

未授權的訪問

提供敏感或限制性信息的 Web Services 應對其調用者進行身份驗證和授權。攻擊者可以利用弱的身份驗證和授權機制，對敏感信息和操作進行未授權的訪問。

漏洞

可導致通過 Web Services 進行未授權的訪問的漏洞包括：

對策

可以使用下列對策防止未授權的訪問：

參數(shù)操縱

參數(shù)操縱是指對 Web Services 客戶與 Web Services 之間發(fā)送的數(shù)據(jù)進行未經(jīng)授權的修改。例如，攻擊者可以截獲 Web Services 消息（例如，在通過中間節(jié)點到達目標的路由中），然后在將其發(fā)送到目標終結點前對其進行修改。

漏洞

可能用于參數(shù)操縱的漏洞包括：

對策

可以使用下列對策來防止參數(shù)操縱：

網(wǎng)絡竊聽

通過網(wǎng)絡竊聽，當 Web Services 消息在網(wǎng)絡中傳輸時，攻擊者可以查看這些消息。例如，攻擊者可以使用網(wǎng)絡監(jiān)視軟件檢索 SOAP 消息中包含的敏感數(shù)據(jù)。其中有可能包括敏感的應用程序級別的數(shù)據(jù)或憑據(jù)信息。

漏洞

可以導致成功的網(wǎng)絡竊聽的漏洞包括：

對策

可以使用下列對策來保護敏感的 SOAP 消息在網(wǎng)絡中傳遞：

配置數(shù)據(jù)的泄漏

Web Services 配置數(shù)據(jù)的泄漏的方法主要有兩種。第一種，Web Services 可能支持動態(tài)生成 Web Services 描述語言 (WSDL)，或者可能在 Web 服務器上的可下載文件中提供 WSDL 信息。取決于具體情況，可能不需要此方法。

注意：WSDL 描述 Web Services 的特征，例如，它的方法簽名和支持的協(xié)議。

第二種，如果異常處理不充分，Web Services 可能會泄漏對攻擊者有用的敏感的內部實施詳細信息。

漏洞

可以導致配置數(shù)據(jù)的泄漏的漏洞包括：

對策

可以使用下列對策防止意外配置數(shù)據(jù)的泄漏：

消息重播

Web Services 消息可能會在傳遞過程中經(jīng)過多個中間服務器。通過消息重播攻擊，攻擊者可以捕獲并復制消息，并模擬客戶端將其重播到 Web Services。消息可能被修改，也可能保持不變。

漏洞

可以導致消息重播的漏洞包括：

攻擊

最常見的消息重播攻擊包括：

對策

可以使用下列對策解除消息重播的威脅：

返回頁首

設計注意事項

準備開發(fā) Web Services 之前，需要在設計階段考慮許多問題。主要的安全注意事項包括：

身份驗證要求

如果 Web Services 提供了敏感或限制性信息，就需要對調用者進行身份驗證以便授權。在 Windows 環(huán)境中，可以使用 Windows 身份驗證。然而，如果無法同時控制兩個終結點，則可以使用 WSE。WSE 提供了遵守最新 WS-Security 標準的身份驗證解決方案。WSE 提供了一個標準框架，可以使用 SOAP 頭信息以用戶名和密碼、Kerberos 票證、X.509 證書或自定義令牌來傳遞身份驗證的詳細信息。有關詳細信息，請參閱本模塊后面的身份驗證部分。

隱私和完整性要求

如果在 Web Services 的請求或響應消息中傳遞敏感的應用程序數(shù)據(jù)，應考慮如何確保這些數(shù)據(jù)在傳輸過程中處于保密狀態(tài)，并且沒有被更改。WSE 通過數(shù)字簽名提供了完整性檢查，并且還支持 XML 加密，對整個消息負載的敏感元素進行加密。此方法的優(yōu)點在于它是基于最新的 WS-Security 標準，并為通過多個中間節(jié)點傳遞的消息提供了一種解決方案。

另外一種方法是使用通過 SSL 或 IPSec 通道的傳輸級別加密。該方案僅適用于可以同時控制兩個終結點的情況。

資源訪問標識

默認情況下，ASP.NET Web Services 不進行模擬，并使用權限最小的 ASPNET 進程帳戶訪問本地和遠程資源。可以使用此 ASPNET 進程帳戶訪問遠程網(wǎng)絡資源，例如，可以通過在數(shù)據(jù)庫服務器上創(chuàng)建本地帳戶的鏡像，來訪問 SQL Server（需要 Windows 身份驗證）。

注意：在 Windows Server 2003 上，默認情況下使用 Network Service 帳戶運行 Web Services。

有關使用 ASP.NET 進程帳戶遠程訪問數(shù)據(jù)庫的詳細信息，請參閱模塊 19 確保 ASP.NET 應用程序和 Web 服務的安全中的“數(shù)據(jù)訪問”部分。

如果使用模擬，Web 應用程序出現(xiàn)的各種問題和注意事項同樣也出現(xiàn)于 Web Services。有關詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件和模塊 19 確保 ASP.NET 應用程序和 Web 服務的安全中的“模擬”部分。

代碼訪問安全

以目標部署環(huán)境中的安全策略定義的信任級別為例。Web Services 的信任級別，是由該服務的 <trust> 元素配置定義的，可以影響該服務訪問的資源類型和其他可執(zhí)行的特權操作。

同樣，如果從 ASP.NET Web 應用程序調用 Web Services，則該 Web 應用程序的信任級別就決定了可以調用的 Web Services 的范圍。例如，信任級別配置為中等信任的 Web 應用程序，在默認情況下只能調用本地計算機上的 Web Services。

有關從中等信任或其他部分信任的 Web 應用程序調用 Web Services 的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。

返回頁首

輸入驗證

如同所有接受數(shù)據(jù)輸入的應用程序一樣，Web Services 也必須驗證所接收的數(shù)據(jù)，以便實施業(yè)務規(guī)則和防止可能的安全問題。標記為 WebMethod 屬性的 Web 方法是 Web Services 的入口點。Web 方法可以接受強類型的輸入?yún)?shù)或通常以字符串數(shù)據(jù)傳遞的松散類型的參數(shù)。這通常取決于設計 Web Services 的客戶的范圍和類型。

強類型參數(shù)

如果使用由 .NET Framework 類型系統(tǒng)描述的強類型參數(shù)（例如 integer、double、date）或其他自定義的對象類型（如 Address 或 Employee），則自動生成的 XML Schema Definition (XSD) 架構就會包含該數(shù)據(jù)的類型描述。客戶可以使用該類型描述，在發(fā)送到 Web 方法的 SOAP 請求中，構造適當格式的 XML。然后 ASP.NET 使用 System.Xml.Serialization.XmlSerializer 類將傳入的 SOAP 消息反序列化為公共語言運行庫 (CLR) 對象。以下示例顯示了一個 Web 方法，該方法可以接受包含內置數(shù)據(jù)類型的強類型輸入。

[WebMethod] 
public void CreateEmployee(string name, int age, decimal salary) {...} 

在上一個示例中，.NET Framework 類型系統(tǒng)自動進行類型檢查。要驗證 name 字段提供的字符的范圍，可以使用正則表達式。例如，下列代碼顯示了如何使用 System.Text.RegularExpressions.Regex 類來限制輸入字符的可能范圍，并驗證參數(shù)的長度。

if (!Regex.IsMatch(name, @"^[a-zA-Z'.`-′\s]{1,40}$"))
{
// 無效的名稱
}

有關正則表達式的詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件中的“輸入驗證”部分。下列示例顯示了一個接受自定義的 Employee 數(shù)據(jù)類型的 Web 方法。

using Employees;  // 自定義命名空間
[WebMethod] 
	
public void CreateEmployee(Employee emp) { ...  }

客戶需要了解 XSD 架構以便能夠調用 Web Services。如果該客戶是一個 .NET Framework 客戶端應用程序，則可以簡單地傳遞一個 Employee 對象，如下所示：

using Employees; 
Employee emp = new Employee(); 
// 填充 Employee 字段
// 向 Web Services 發(fā)送 Employee
wsProxy.CreateEmployee(emp); 

對于不是基于 .NET Framework 的客戶應用程序，必須根據(jù)負責此 Web Services 的組織所提供的架構定義，手動構造 XML 輸入。

這種強類型方法的優(yōu)點是，.NET Framework 可以對輸入數(shù)據(jù)進行解析，并根據(jù)類型定義驗證這些數(shù)據(jù)。然而，您可能還需要在此 Web 方法內部對輸入數(shù)據(jù)進行限制。例如，盡管類型系統(tǒng)確認 Employee 對象有效，然而可能還需要對 Employee 的各個字段進一步驗證。您可能需要驗證雇員的年齡是否大于 18 歲。還可能需要使用正則表達式，來限制 name 字段使用的字符的范圍等等。

有關限制輸入的詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件中的“輸入驗證”部分。

松散類型的參數(shù)

如果使用字符串參數(shù)或字節(jié)數(shù)組傳遞任意數(shù)據(jù)，將會失去 .NET Framework 類型系統(tǒng)的許多優(yōu)點。您必須手動解析輸入數(shù)據(jù)，以便對其進行驗證，因為自動生成的 WSDL 僅將這些參數(shù)簡單描述為 xsd:string 類型的字符串輸入。您需要以編程方式檢查類型、長度、格式和范圍，如下例所示。

[WebMethod] 
public void SomeEmployeeFunction(string dateofBirth, string SSN)  
{
    . . . 
// 示例 1：對日期進行類型檢查
try 
  {
DateTime dt = DateTime.Parse(dateofBirth).Date; 
  }
// 如果類型轉換失敗就會拋出 FormatException 異常
catch( FormatException ex ) 
  {
// 無效的日期
  }
  
// 示例 2：檢查社會安全保險號的長度、格式和范圍
if( !Regex.IsMatch(empSSN,@"^\d{3}-\d{2}-\d{4}$",RegexOptions.None))  
  {
// 無效的社會安全保險號
  }
}

XML 數(shù)據(jù)

在經(jīng)典的商業(yè)對商業(yè)方案中，客戶經(jīng)常傳遞表示業(yè)務文檔（如購貨訂單或銷售發(fā)票）的 XML 數(shù)據(jù)。在對這些輸入數(shù)據(jù)進行處理或將其傳遞到下游組件之前，必須通過 Web 方法以編程方式驗證這些輸入數(shù)據(jù)的有效性。

客戶端和服務器必須建立描述 XML 的架構，并達成一致。下列代碼片段顯示了 Web 方法如何使用 System.Xml.XmlValidatingReader 類來驗證輸入數(shù)據(jù)。本例中的輸入數(shù)據(jù)描述了一個簡單的圖書訂單。請注意，這些 XML 數(shù)據(jù)是通過簡單的字符串參數(shù)傳遞的。

using System.Xml; 
using System.Xml.Schema; 

[WebMethod] 
public void OrderBooks(string xmlBookData) 
{
try  
  {
// 創(chuàng)建并加載一個驗證的 reader
XmlValidatingReader reader = new XmlValidatingReader(xmlBookData,  
XmlNodeType.Element,  
null); 
// 將 XSD 架構附加在此 reader 上
reader.Schemas.Add("urn:bookstore-schema",  
@"http://localhost/WSBooks/bookschema.xsd"); 
// 設置 XSD 架構的驗證類型。 
// 也支持 XDR 架構和 DTD
reader.ValidationType = ValidationType.Schema; 
// 創(chuàng)建并注冊一個事件處理器，來處理驗證錯誤
reader.ValidationEventHandler += new ValidationEventHandler( 
ValidationErrors ); 
// 處理輸入數(shù)據(jù)
while (reader.Read()) 
    {
      . . .
    }
// 驗證成功完成
  }
catch 
  {
   . . .
  }
}

// 驗證錯誤事件處理器
private static void ValidationErrors(object sender, ValidationEventArgs args) 
{
// 從 args.Message 獲得的錯誤詳細信息
  . . .
}

下列代碼片段顯示了客戶如何調用以上 Web 方法：

string xmlBookData = "<book  xmlns='urn:bookstore-schema'  
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>" + 
"<title>Building Secure ASP.NET Applications</title>" + 
"<isbn>0735618909</isbn>" + 
"<orderQuantity>1</orderQuantity>" + 
"</book>"; 
BookStore.BookService bookService = new BookStore.BookService(); 
bookService.OrderBooks(xmlBookData)); 

以上示例使用了下列簡單的 XSD 架構來驗證輸入數(shù)據(jù)。

  
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
xmlns="urn:bookstore-schema"  
elementFormDefault="qualified"  
targetNamespace="urn:bookstore-schema"> 
<xsd:element name="book" type="bookData"/> 
<xsd:complexType name="bookData"> 
<xsd:sequence> 
<xsd:element name="title" type="xsd:string" /> 
<xsd:element name="isbn" type="xsd:integer" /> 
<xsd:element name="orderQuantity" type="xsd:integer"/> 
</xsd:sequence> 
</xsd:complexType> 
</xsd:schema> 

下表顯示了其他復雜的元素定義，它們可以用于 XSD 架構以便進一步限制各個 XML 元素。

表 12.1：XSD 架構元素示例

<xsd:element name="zip"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:pattern value="\d{5}(-\d{4})?"  />
</xsd:restriction> 
</xsd:simpleType> 
</xsd:element> 

<xsd:element name="Salary"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:decimal"> 
<xsd:fractionDigits value="2" /> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:element> 

<xsd:element name="FirstName"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:maxLength value="50" /> 
<xsd:minLength value="2" /> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:element> 

<xsd:element name="Gender"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Male" /> 
<xsd:enumeration value="Female" /> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:element> 

有關詳細信息，請參閱下列 Microsoft 知識庫文章：

SQL 注射

“SQL 注射”允許攻擊者使用 Web Services 的數(shù)據(jù)庫登錄在數(shù)據(jù)庫中執(zhí)行任意命令。如果 Web Services 使用輸入數(shù)據(jù)來構造 SQL 查詢，就可能存在 SQL 注射問題。如果 Web 方法訪問此數(shù)據(jù)庫，使用的應該是 SQL 參數(shù)，并且在理想情況下，是參數(shù)化的存儲過程。SQL 參數(shù)會驗證輸入數(shù)據(jù)的類型和長度，并確保將其視為文本而不是可執(zhí)行代碼。有關 SQL 注射的所有對策的詳細信息，請參閱模塊 14 構建安全的數(shù)據(jù)訪問中的“輸入驗證”部分。

跨站點腳本

通過跨站點腳本 (XSS)，攻擊者可以利用您的應用程序在客戶端執(zhí)行惡意腳本。如果從 Web 應用程序調用 Web Services，并將 Web Services 的輸出結果以 HTML 數(shù)據(jù)流的形式發(fā)送回客戶端，就有可能存在 XSS 問題。在這種情況下，應在 Web 應用程序中對從 Web Services 接收的輸出結果進行編碼，然后再將其返回給客戶端。如果您不擁有此 Web Services，并且該服務在 Web 應用程序的信任邊界之外，這樣做尤其重要。有關 XSS 對策的詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件中的“輸入驗證”部分。

返回頁首

身份驗證

如果 Web Services 輸出敏感的、受限制的數(shù)據(jù)，或者提供受限制的服務，則需要對調用者進行身份驗證。可用的身份驗證方案有許多，大致可以分為以下三類：

平臺級別的身份驗證

如果可以同時控制這兩個終結點，并且它們在相同的域或信任域中，則可以使用 Windows 身份驗證對調用者進行身份驗證。

基本身份驗證

可以使用 IIS 來配置 Web Services 的虛擬目錄，以便進行基本身份驗證。如果使用此方法，客戶必須配置代理服務器，并提供用戶名和密碼形式的憑據(jù)。然后代理服務器將其與通過此代理服務器的每個 Web Services 請求一起傳輸。憑據(jù)是以明文形式傳輸?shù)模虼藨獌H使用有 SSL 的基本身份驗證。

下列代碼片段顯示了 Web 應用程序如何提取最終用戶提供的基本身份驗證憑據(jù)，然后使用這些憑據(jù)調用 IIS 中的下游 Web Services 進行基本身份驗證。

// 檢索客戶端憑據(jù)（可用于基本身份驗證）
string pwd = Request.ServerVariables["AUTH_PASSWORD"]; 
string uid = Request.ServerVariables["AUTH_USER"]; 
// 設置憑據(jù)
CredentialCache cache = new CredentialCache(); 
cache.Add( new Uri(proxy.Url), // Web Services  URL
"Basic", 
new NetworkCredential(uid, pwd, domain) ); 
proxy.Credentials = cache; 

集成的 Windows 身份驗證

可以使用 IIS 來配置 Web Services 的虛擬目錄，以便進行集成的 Windows 身份驗證，從而根據(jù)客戶端和服務器環(huán)境的不同進行 Kerberos 或 NTLM 身份驗證。相對于基本身份驗證，這種方法的優(yōu)點是憑據(jù)不通過網(wǎng)絡傳遞，從而排除了網(wǎng)絡竊聽的威脅。

要調用配置為集成 Windows 身份驗證的 Web Services，客戶必須顯式地配置代理服務器上的“憑據(jù)”屬性。

要以客戶端的 Windows 安全上下文（來自模擬的線程令牌或進程令牌）覆蓋 Web Services，可以將此 Web Services 代理的“憑據(jù)”屬性設置為 CredentialCache.DefaultCredentials，如下所示。

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials; 

還可以使用如下所示的一組明確憑據(jù)：

CredentialCache cache = new CredentialCache(); 
cache.Add( new Uri(proxy.Url), // Web Services  URL
"Negotiate",         // Kerberos 或 NTLM
new NetworkCredential(userName, password, domain)); 
proxy.Credentials = cache; 

如果需要指定明確憑據(jù)，請不要將其硬編碼或存儲到明文中。可以使用 DPAPI 加密帳戶憑據(jù)，并將加密數(shù)據(jù)存儲在 Web.config 的 <appSettings> 元素中或受限制的注冊表項下。

有關平臺級別的身份驗證的詳細信息，請參閱“Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications:Authentication, Authorization, and Secure Communication”中的“Web Services Security”部分，其網(wǎng)址為：http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true（英文）。

消息級別的身份驗證

可以使用 WSE 來實現(xiàn)符合最新 WS-Security 標準的消息級別的身份驗證解決方案。此方法允許使用 SOAP 頭信息以標準形式傳遞身份驗證令牌。

注意：如果雙方同意使用 WS-Security，也必須就身份驗證令牌的準確格式達成一致。

WSE 可以使用和支持下列類型的身份驗證令牌：

用戶名和密碼

可以在 SOAP 頭信息中發(fā)送用戶名和密碼憑據(jù)。然而，由于它們是以明文發(fā)送的，存在網(wǎng)絡竊聽的威脅，因此該方法應與 SSL 一起使用。憑據(jù)是作為 SOAP 頭信息中的 <Security> 元素的一部分發(fā)送的，如下所示。

<wsse:Security 
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> 
<wsse:UsernameToken> 
<wsse:Username>Bob</wsse:Username>  
<wsse:Password>YourStr0ngPassWord</wsse:Password> 
</wsse:UsernameToken> 
</wsse:Security> 

用戶名和密碼摘要

您可以發(fā)送密碼摘要，而不是發(fā)送明文密碼。摘要是 Base64（UTF8 的編碼 SHA1 哈希值）編碼的密碼。然而，除非在安全通道上使用此方法，否則擁有網(wǎng)絡監(jiān)視軟件的攻擊者仍然可以截獲數(shù)據(jù)，并重新使用這些數(shù)據(jù)來非法訪問您的 Web Services。要解決這種重播攻擊的威脅，該摘要可以結合 Nonce 和創(chuàng)建時間戳一起使用。

有 Nonce 和時間戳的用戶名和密碼摘要

在此方法中，摘要是 Nonce 值、創(chuàng)建時間戳和密碼的 SHA1 哈希。

digest = SHA1(Nonce + creation timestamp + password) 

此方法中的 Web Services 必須維護一個包含 Nonce 值的表，并拒絕包含重復 Nonce 值的任何消息。盡管此方法有助于保護密碼，并為防止重播攻擊提供了基礎，但在計算過期日期時，客戶與提供商之間會出現(xiàn)時鐘同步的問題，而且它不能防止攻擊者捕獲消息、修改 Nonce 值，然后將此消息重播給 Web Services。要解決此威脅，必須對消息進行數(shù)字簽名。通過 WSE，可以使用自定義的令牌或 X.509 證書對消息進行簽名。此方法可以基于公鑰/私鑰對來防止篡改和提供身份驗證。

Kerberos 票證

可以發(fā)送包含 Kerberos 票證的安全令牌，如下所示。

<wsse:Security 
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> 
<wsse:BinarySecurityToken 
ValueType="wsse:Kerberosv5ST" 
EncodingType="wsse:Base64Binary"> 
U87GGH91TT ... 
</wsse:BinarySecurityToken> 
</wsse:Security> 

X.509 證書

還可以發(fā)送一個作為身份驗證令牌的 X.509 證書來提供身份驗證。

<wsse:Security 
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> 
<wsse:BinarySecurityToken 
ValueType="wsse:X509v3" 
EncodingType="wsse:Base64Binary"> 
Hg6GHjis1 ...         
</wsse:BinarySecurityToken> 
</wsse:Security> 

有關以上方法的詳細信息，請參閱 WSE 附帶的示例。

應用程序級別的身份驗證

通過讓應用程序使用自定義的 SOAP 頭信息，可以設計和構建您自己的自定義身份驗證。在此之前，應檢查平臺和 WSE 提供的功能，以查看這些功能是否可用。如果必須使用自定義身份驗證機制，而且需要加密，可以使用 System.Security.Cryptography 命名空間提供的標準加密算法。

返回頁首

授權

身份驗證以后，根據(jù)調用者的身份或角色成員關系，可以將其限制在 Web Services 提供的部分功能內。可以限制對服務終結點（在 .asmx 文件級別上）、各個 Web 方法或 Web 方法內的特定功能的訪問。

Web Services 終結點身份驗證

如果將 Web Services 配置成集成的 Windows 身份驗證，則可以基于最初的調用者的安全上下文，在 Web Services (.asmx) 的文件上配置 NTFS 權限來控制訪問。這種授權是由 ASP.NET 的 FileAuthorizationModule 執(zhí)行的，而且不需要模擬。

不管哪種類型的身份驗證，都可以使用 ASP.NET 的 UrlAuthorizationModule 來控制對 Web Services (.asmx) 文件的訪問。通過將 <allow> 和 <deny> 元素添加到 Machine.config 或 Web.config 中的 <authorization> 元素中，可以實現(xiàn)此配置。

有關這兩種形式授權的詳細信息，請參閱模塊 19 確保 ASP.NET 應用程序和 Web 服務的安全中的“授權”部分。

Web 方法授權

可以根據(jù)調用者的身份或角色成員關系，使用說明性的主要權限需求來控制對每個 Web 方法的訪問。調用者的身份和角色成員關系是由與當前的 Web 請求（通過 HttpContext.User 來訪問）相關的主要對象來維護。

[PrincipalPermission(SecurityAction.Demand, Role=@"Manager")] 
[WebMethod] 
public string QueryEmployeeDetails(string empID) 
{
}

有關主要權限需求的詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件中的“授權”部分。

編程授權

通過調用 Web 方法中的 IPrincipal.IsInRole，可以使用命令性的權限檢查或明確的角色檢查，進行精確的授權邏輯，如下所示。

// 在此假設使用非 Windows 身份驗證。使用 Windows 身份驗證
// 將 User 對象轉換為 WindowsPrincipal 對象并使用 Windows 組作為
// 角色名
GenericPrincipal user = User as GenericPrincipal; 
if (null != user) 
{
if ( user.IsInRole(@"Manager") ) 
  {
// 授予用戶執(zhí)行管理功能
  }
}

返回頁首

敏感數(shù)據(jù)

如果 Web Services 的請求或響應消息用于傳遞敏感的應用程序數(shù)據(jù)，如信用卡號、雇員詳細信息等，則必須解決在中間應用程序節(jié)點上存在的網(wǎng)絡竊聽或信息泄漏的威脅。

在封閉的環(huán)境中，可以同時控制兩個終結點，此時可以使用 SSL 或 IPSec 來提供傳輸層加密。在其他環(huán)境中，如果消息是通過中間應用程序節(jié)點路由的，則需要消息級別的解決方案。根據(jù) WWW 聯(lián)合會 (W3C) XML 加密標準，WS-Security 標準定義了一個機密性服務，允許在傳輸 SOAP 頭信息之前對其進行部分或全部加密。

XML 加密

可以使用以下三種方法全部或部分加密 SOAP 消息：

使用 X.509 證書的非對稱加密

通過此方法，客戶可以使用 X.509 證書的公鑰部分來加密 SOAP 消息。這種加密只能由擁有相應私鑰的服務來解密。

Web Services 必須能夠訪問相關的私鑰。默認情況下，WSE 在本地計算機的存儲區(qū)中搜索 X.509 證書。可以使用 Web.config 中的 <x509> 配置元素將存儲位置設置為當前的用戶存儲區(qū)，如下所示。

<configuration> 
<microsoft.web.services> 
<security> 
<x509 storeLocation="CurrentUser" /> 
</security> 
</microsoft.web.services> 
</configuration> 

如果使用用戶存儲區(qū)，則必須加載 Web Services 的進程帳戶的用戶配置文件。如果使用默認的 ASPNET（權限最小的本地帳戶） 運行 Web Services，則 .NET Framework 版本 1.1 將加載此帳戶的用戶配置文件，從而訪問此用戶密鑰的存儲區(qū)。

對于使用 .NET Framework 版本 1.0 構建的 Web Services，則不會加載 ASPNET 用戶配置文件。在這種情況下，有以下兩種選擇。

\Documents and Settings\All Users\Application Data\ 
Microsoft\Crypto\RSA\MachineKeys 

有關詳細信息，請參閱 WSE 文檔中的“管理 X.509 證書”、“使用 X.509 證書加密 SOAP 消息”以及“使用 X.509 證書解密 SOAP 消息”部分。

使用共享密鑰的對稱加密

使用對稱加密，Web Services 及其客戶可以共享一個密鑰來加密和解密 SOAP 消息。盡管客戶和服務提供商必須使用某些“不合適”的機制來共享密鑰，不過這種加密比非對稱加密速度快。

有關詳細信息，請參閱 WSE 文檔中的“使用共享密鑰加密 SOAP 消息”和“使用共享密鑰解密 SOAP 消息”部分。

使用自定義二進制令牌的對稱加密

您還可以使用 WSE 定義一個自定義的二進制令牌，來封裝用于加密和解密消息的自定義安全憑據(jù)。此時，代碼需要以下兩個類。sender 類必須從 BinarySecurityToken 類派生，以便封裝自定義安全憑據(jù)，并加密消息。recipient 類必須從 DecryptionkeyProvider 類派生，以便檢索密鑰并解密消息。

有關詳細信息，請參閱 WSE 文檔中的“使用自定義二進制安全令牌加密 SOAP 消息”和“使用自定義二進制安全令牌解密 SOAP 消息”部分。

加密部分消息

默認情況下，WSE 加密整個 SOAP 正文，而且不加密 SOAP 頭信息。然而，還可以使用 WSE 以編程方式加密和解密部分消息。

有關詳細信息，請參閱 WSE 文檔中的“指定要簽名或加密的部分 SOAP 消息”部分。

返回頁首

參數(shù)操縱

Web Services 的參數(shù)操縱是一種威脅，當消息請求或響應在客戶與服務之間傳遞時，攻擊者可以使用某種方法更改消息負載。

要解決此威脅，可以對 SOAP 消息進行數(shù)字簽名，允許消息收件人通過密碼來驗證此消息自接受簽名以來是否被更改過。有關詳細信息，請參閱 WSE 文檔中的“對 SOAP 消息進行數(shù)字簽名”部分。

返回頁首

異常管理

返回給客戶的異常詳細信息只能包含最低限度的信息，而且不應泄漏任何內部實施細節(jié)。例如，下面是一個已經(jīng)允許傳播給客戶的系統(tǒng)異常示例。

System.Exception:User not in managers role（用戶不是管理員角色） 
at EmployeeService.employee.GiveBonus(Int32 empID, Int32 percentage) in  
c:\inetpub\wwwroot\employeesystem\employee.asmx.cs:line 207 

上述異常的詳細信息向該服務的客戶泄漏了目錄結構和其他詳細信息。惡意用戶可以使用這些信息獲得虛擬目錄的路徑，以便進一步攻擊。

Web Services 可以拋出以下三種類型的異常：

不管哪種異常類型，異常的詳細信息都使用標準的 SOAP <Fault> 元素傳播到客戶端。客戶端和由 ASP.NET 創(chuàng)建的 Web Services 并不直接解析 <Fault> 元素，而是通常用 SoapException 對象來處理。這允許客戶端設置 try 塊，來捕獲 SoapException 對象。

注意：如果從自定義的 HTTP 模塊中拋出 SoapException，則該異常不會自動序列化為 SOAP <Fault> 元素。在這種情況下，必須手動創(chuàng)建 SOAP <Fault> 元素。

使用 SoapException

下列代碼顯示了一個簡單的 WebMethod，由于應用程序邏輯驗證失敗，因而生成異常。發(fā)送到客戶端的錯誤信息已降到最少。在此示例中，為客戶端提供了可以用來尋求支持的幫助臺參考信息。在 Web 服務器上，供幫助臺參考的詳細錯誤描述被記錄下來，以便幫助支持人員診斷問題。

using System.Xml; 
using System.Security.Principal; 

[WebMethod] 
public void GiveBonus(int empID, int percentage) 
{
// 僅管理人員可以發(fā)放獎金
// 本示例使用 Windows 身份驗證
WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal); 
if( wp.IsInRole(@"Domain\Managers"))  
  {
// 授予用戶發(fā)放獎金的權限
     . . .
  }
else 
  {
// 在服務器上記錄錯誤詳細信息。例如： 
// DOMAIN\Bob 試圖為 ID 為 345667 的雇員發(fā)放獎金。
// 由于 DOMAIN\Bob 不是管理人員，因此拒絕訪問。
// 注意：用戶名可以從 wp.Identity.Name 獲得

// 使用 SoapException 向客戶端返回最少的錯誤信息
XmlDocument doc = new XmlDocument(); 
XmlNode detail = doc.CreateNode(XmlNodeType.Element, 
SoapException.DetailElementName.Name, 
SoapException.DetailElementName.Namespace); 
// 這是此異常的詳細部分
detail.InnerText = "User not authorized to perform requested operation";
throw new SoapException("Message string from your Web service（來自您的 Web Services 的消息字符串）",  
SoapException.ServerFaultCode,  
Context.Request.Url.AbsoluteUri, detail, null ); 
  } 
}

用于處理可能的 SoapException 的客戶代碼如下：

try 
{
EmployeeService service = new EmployeeService(); 
Service.GiveBonus(empID,percentage); 
}
catch (System.Web.Services.Protocols.SoapException se) 
{
// 從 se.Detail.InnerText 提取自定義消息
Console.WriteLine("Server threw a soap exception" + se.Detail.InnerText ); 
}

Global.asax 中的應用程序級別的錯誤處理

ASP.NET Web 應用程序通常在 Global.asax 的 Application_Error 事件處理程序中處理那些被允許越過方法邊界傳播的應用程序級異常。此功能并不適用于 Web Services，因為 Web Services 的 HttpHandler 在異常到達其他處理程序之前已經(jīng)將其捕獲。

如果需要應用程序級別的異常處理，可以創(chuàng)建自定義的 SOAP 擴展來處理它。有關詳細信息，請參閱 Microsoft? .NET Framework SDK 1.1 版的“Building Applications”部分中的 MSDN 文章：Altering the SOAP Message using SOAP Extensions。

返回頁首

審核與日志記錄

通過 Web Services，可以使用平臺級別的功能或在 Web 方法實現(xiàn)中使用自定義代碼，來審核和記錄行為的詳細信息和事務。

可以使用 System.Diagnostics.EventLog 類來編寫代碼，將操作記錄到 Windows 事件日志中。從 Web Services 使用此類的權限要求和技術與 Web 應用程序的權限要求和技術相同。有關詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網(wǎng)頁和控件中的“審核與日志記錄”部分。

返回頁首

代理服務器的注意事項

如果使用 WSDL 自動生成一個代理服務器類以便與 Web Services 通信，應驗證生成的代碼和服務終結點，以確保與所需的 Web Services 通信，而不是與欺騙性服務通信。如果遠程服務器上的 WSDL 文件保護不當，惡意用戶就有可能篡改此文件，并更改終結點的地址，從而影響生成的代理服務器代碼。

尤其應檢查 .wsdl 文件中的 <soap:address> 元素，并驗證其是否指向所希望的位置。如果使用 Visual Studio .NET，并通過使用“添加 Web 引用”對話框來添加 Web 引用，應向下滾動并檢查服務終結點。

最后，不管是使用 Visual Studio.NET 來添加 Web 引用，還是使用 Wsdl.exe 手動生成代理服務器代碼，都應仔細檢查代理服務器代碼并查找任何可疑代碼。

注意：可以將 Web Services 代理的“URL 行為”屬性設置為“動態(tài)”，從而可以在 Web.config 中指定終結點的地址。

返回頁首

代碼訪問安全的注意事項

代碼訪問安全可以限制所訪問的資源和由 Web Services 代碼執(zhí)行的操作。ASP.NET Web Services 服從于由 Web Services 的 <trust> 元素所配置的 ASP.NET 代碼訪問安全策略。

代碼訪問安全策略必須將 WebPermission 權限授予調用 Web Services 的 .NET Framework 客戶代碼。WebPermission 權限的準確狀態(tài)決定了可以調用的 Web Services 的范圍。例如，可以對代碼進行限制，使其只能調用本地 Web Services 或指定服務器上的服務。

如果完全信任客戶代碼，則可以授予其不受限制的 WebPermission 權限，從而可以調用任意 Web Services。部分信任的客戶代碼受到下列限制：

有關從部分信任的 Web 應用程序調用 Web Services 的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。有關 WebPermission 的詳細信息，請參閱模塊 8 代碼訪問安全的實踐中的“Web 服務”部分。

返回頁首

部署注意事項

可用的安全選項的范圍主要取決于 Web Services 試圖包含的特定部署方案。如果構建的應用程序在 Intranet 內使用 Web Services，則可以隨意使用最多的安全選項和技術。然而，如果 Web Services 可以通過 Internet 公開訪問，則可以使用的選項就受到很大限制。本節(jié)描述了各種部署方案的適用性的含義，這些方法可以保護本模塊先前討論的 Web Services 的安全。

Intranet 部署

由于可以控制客戶應用程序、服務和平臺，Intranet 通常可以提供最多的可用選項以保護 Web Services 的安全。

在 Intranet 情況下，通常可以從整個身份驗證和安全通信選項中選擇。例如，如果客戶和服務在相同域或信任域中，則可以考慮使用 Windows 身份驗證。您可以指定客戶端應用程序開發(fā)人員設置客戶端代理服務器的憑據(jù)屬性，將用戶的 Windows 憑據(jù)發(fā)送到 Web Services。

Intranet 通信通常在專用網(wǎng)絡上進行，具有一定的安全性。如果這樣還不滿足，可以考慮使用 SSL 對通信進行加密。還可以使用消息級別的安全，并在客戶端和服務器上都安裝 WSE，在這兩個終結點上對應用程序透明地處理安全事務。WSE 支持身份驗證、數(shù)字簽名和加密。

Extranet 部署

在 Extranet 情況下，可能需要通過 Internet 將 Web Services 提供給數(shù)量有限的合作伙伴。盡管被管理的客戶端應用程序來自分散的、獨立的環(huán)境，用戶團體仍然可以了解、預測并且可能使用它們。在這種情況下，需要一種適合雙方的、并且不依賴于受信任域的身份驗證機制。

如果使帳戶信息對雙方都可用，則可以使用基本身份驗證。如果使用基本身份驗證，應確保使用 SSL 來保護憑據(jù)的安全。

注意：SSL 僅保護通過網(wǎng)絡的憑據(jù)。如果惡意用戶在客戶端計算機上成功安裝代理工具（如 sslproxy）以截獲調用信息，然后通過 SSL 將其轉發(fā)到 Web Services，此時 SSL 并不保護這些憑據(jù)。

Extranet 可以使用的另外一個選項是，使用 IIS 客戶端證書身份驗證，而不是傳遞顯式憑據(jù)。在這種情況下，調用方應用程序在調用時必須攜帶有效的證書。Web Services 使用此證書對調用者進行身份驗證，并對此操作進行授權。有關詳細信息，請參閱 MSDN 文章“Building Secure ASP.NET Applications”中的“Extranet Security”部分，其網(wǎng)址為：http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch06.asp（英文）。

Internet 部署

如果為大量 Internet 客戶提供 Web Services，并且需要進行身份驗證，則可用的選項非常有限。由于客戶無法將其憑據(jù)映射到合適的域帳戶，因此任何形式的平臺級別身份驗證都不合適。如果目標 IIS Web 服務器或其前面的 ISA 服務器必須知道大量客戶端證書，則使用 IIS 客戶端證書身份驗證和傳輸 (SSL) 級別的身份驗證也會出現(xiàn)問題。此時最合適的選擇只剩下消息和應用程序級別的身份驗證和授權。由服務的客戶所傳遞的憑據(jù)是以用戶名、密碼、證書、Kerberos 票證或自定義令牌的形式傳遞的，可以由 Web Services 基礎結構 (WSE) 透明地進行驗證，或在目標服務內以編程方式進行驗證。客戶端證書很難大規(guī)模管理。密鑰管理（包括發(fā)出和吊銷）也會出現(xiàn)問題。同時，基于證書的身份驗證占用大量資源，因此有大量客戶端時，其伸縮性就成為問題。

SSL 通常只加密服務器端證書的網(wǎng)絡通信，不過還可以通過消息級別的加密來彌補。

從安全的角度來說，使用客戶端證書有其優(yōu)點，但當有大量用戶時，通常就會出現(xiàn)問題。您必須仔細管理證書，并考慮如何將其傳送給客戶端、續(xù)訂、吊銷等問題。Internet 情況下的另一個可能問題是該解決方案的整體可伸縮性。對于大規(guī)模的 Web Services 來說，其工作量非常大，因而操作開銷或加密/解密和證書驗證可能導致問題。

返回頁首

小結

WS-Security 是 Web Services 安全的最新標準。規(guī)范中定義了身份驗證的選項，可以通過使用 SOAP 頭信息以標準方法傳遞安全令牌。令牌可以包括用戶名和密碼憑據(jù)、Kerberos 票證、X.509 證書或自定義令牌。WS-Security 還可以解決消息的隱私和完整性問題。您可以加密整個或部分消息以提供隱私保護，并對其進行數(shù)字簽名以提供完整性。

在 Intranet 環(huán)境中，由于可以同時控制兩個終結點，因而可以使用平臺級別的安全選項，如 Windows 身份驗證。對于更復雜的環(huán)境，如果沒有同時控制兩個終結點，并且消息要通過中間應用程序節(jié)點進行路由，則需要消息級別的解決方案。下面的“其他參考資料”部分列出了一些網(wǎng)站，可以用來查找最新的 WS-Security 標準及其相關的 WSE 工具包。這些工具包允許構建符合此標準和其他最新 Web Services 標準的解決方案。

返回頁首

其他資源

有關詳細信息，請參閱下列資源：

返回頁首

posted on 2006-06-08 17:05 xiaofeng 閱讀(219) 評論(0)  編輯  收藏