国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

本單元概要

越來越多的公司和單位開始創(chuàng)建和部署 Web 服務。然而，這通常是在并沒有完全了解 Web 服務安全問題的情況下進行的。本單元闡述如何安全地設計、配置和部署 Web 服務。對于任何需要接受外部請求的應用程序，輸入驗證是非常重要的，本單元舉出了一些技術確保只接受格式正確的請求。本單元還詳細解釋了可以用來限制授權用戶對 Web 服務訪問權限、以及確?？蓪τ脩舨僮鬟M行日志記錄和審核的不同身份驗證方法。

本單元還討論了 Microsoft 的 Web 服務s Enhancements 1.0 for Microsoft? .NET (WSE)，它支持 WS-Security（Web 服務安全）標準和相關的一系列新出現(xiàn)的標準。

返回頁首

目標

通過本單元可以：

返回頁首

適用范圍

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

返回頁首

如何使用本單元

要想充分利用本單元：

本頁內(nèi)容

	本單元概要
	目標
	適用范圍
	如何使用本單元
	概述
	威脅與對策
	設計注意事項
	輸入驗證
	身份驗證
	授權
	敏感數(shù)據(jù)
	參數(shù)操作
	異常管理
	審核和日志記錄
	代理注意事項
	代碼訪問安全注意事項
	部署注意事項
	小結
	其他資源

返回頁首

概述

越來越多的公司使用 Web 服務通過 Internet 和公司 Extranet 將自己的產(chǎn)品和服務展示給客戶和商業(yè)伙伴。這些服務提供者的安全需求是極為重要的。在一些情況下，主要是 Intranet 或者 Extranet 場景中，可以在一定程度上控制兩端的終結點，這時可使用操作系統(tǒng)和 Internet 信息服務 (IIS) 所提供的基于平臺的安全服務提供點到點的安全解決方案。但是，Web 服務基于消息的體系結構和跨越信任邊界的異構環(huán)境（Web 服務在此種環(huán)境中的使用越來越多）對我們提出了新的挑戰(zhàn)。這些場景需要在消息級處理安全問題，以支持跨平臺互用性和通過多個中間節(jié)點進行路由。

Web 服務安全 (WS-Security) 是設計用來解決這些問題的新出現(xiàn)的安全標準。Microsoft 已經(jīng)發(fā)布了 Web 服務s Enhancements 1.0 for Microsoft .NET (WSE) ，它支持 WS-Security 以及一系列相關的新出現(xiàn)的標準。WSE 使您可實現(xiàn)消息級安全解決方案，包括身份驗證、加密和數(shù)字簽名。

注 WSE 支持的規(guī)范和標準還在發(fā)展中，因此當前的 WSE 并不能保證會與產(chǎn)品未來的版本兼容。在寫作本單元時，使用其他供應商（包括 IBM 和 VeriSign）提供的非 Microsoft 工具集的互用性測試正在進行。

返回頁首

威脅與對策

為了構建安全的 Web 服務，需要了解相關的威脅。針對 Web 服務的最大威脅主要有：

圖 1 顯示了針對 Web 服務的最大威脅和攻擊。

圖 1. 主要的 Web 服務威脅

未授權訪問

提供敏感或者受限信息的 Web 服務應該對其調(diào)用方進行身份驗證和授權。脆弱的身份驗證和授權會被人利用，以獲取對敏感信息和操作的未授權訪問。

缺陷

可能通過 Web 服務導致未授權訪問的缺陷包括：

對策

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

參數(shù)操作

所謂參數(shù)操作是指對 Web 服務使用者和 Web 服務之間發(fā)送的數(shù)據(jù)進行未授權的修改。例如，可能在通過一個中間節(jié)點向目的地傳輸途中，攻擊者可截獲一個 Web 服務消息，然后在消息發(fā)送到預期終結點之前將其修改。

缺陷

導致參數(shù)操作可能發(fā)生的缺陷包括：

對策

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

網(wǎng)絡偵聽

通過網(wǎng)絡偵聽，攻擊者能夠在 Web 服務消息跨網(wǎng)絡傳輸時查看這些消息。例如，攻擊者可以使用網(wǎng)絡監(jiān)視軟件獲取 SOAP 消息中包含的敏感數(shù)據(jù)?？赡馨舾械膽贸绦蚣墧?shù)據(jù)或者憑據(jù)信息。

缺陷

導致網(wǎng)絡偵聽可能成功實施的缺陷包括：

對策

可以使用以下對策在敏感 SOAP 消息跨網(wǎng)絡傳輸時進行保護：

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

Web 服務泄漏配置數(shù)據(jù)有兩種主要方式。第一種是，Web 服務可以支持 Web 服務描述語言 (WSDL) 的動態(tài)生成或者可支持在 Web 服務器上的可下載文件中提供 WSDL 信息。取決于您所處的場景，這可能是您并不希望發(fā)生的。

注 WSDL 用于說明一個 Web 服務的特性，例如，它的方法簽名和所支持的協(xié)議。

第二種是，由于不適當?shù)漠惓Ｌ幚?，Web 服務可能泄漏對攻擊者有用的敏感的內(nèi)部實現(xiàn)細節(jié)。

缺陷

可能導致配置數(shù)據(jù)泄漏的缺陷包括：

對策

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

消息重放

Web 服務消息可能通過多個中間服務器傳遞。通過消息重放攻擊，攻擊者可捕獲和復制一個消息，并將其重放給模擬客戶端的 Web 服務。消息可能會被修改，也可能不會。

缺陷

導致消息重放可能發(fā)生的缺陷包括：

攻擊

最常見的消息重放攻擊類型包括：

對策

可以使用以下對策應對消息重放威脅：

返回頁首

設計注意事項

在開始開發(fā) Web 服務之前，有一些問題需要在設計時考慮。重要的安全注意事項有：

身份驗證要求

如果您的 Web 服務提供敏感的或者限制性的信息，它需要對調(diào)用方進行身份驗證以支持授權。在 Windows 環(huán)境中，可以使用 Windows 身份驗證。但是，當您不能控制兩端的終結點的時候，可以使用 WSE 提供身份驗證解決方案，這種解決方案遵守新出現(xiàn)的 WS-Security 標準。WSE 為使用 SOAP 頭傳遞身份驗證詳細信息（形式為用戶名和密碼、Kerberos 票證、X.509 證書或者自定義令牌）提供了一個標準框架。有關更多信息，請參閱本單元后面的“身份驗證”部分。

私密性和完整性要求

如果要在 Web 服務請求或者響應消息中傳遞敏感的應用程序數(shù)據(jù)，應該考慮如何才能保證它們在傳輸途中保持私密性、防止被修改。WSE 通過數(shù)字簽名提供了完整性檢查，它還支持 XML 加密以加密整個消息負載中的敏感元素。這種方法的優(yōu)點在于，它是以新出現(xiàn)的 WS-Security 標準為基礎的，它為需要通過多個中間節(jié)點傳遞的消息提供了一種解決方案。

另一種替代方案是通過 SSL 或者 IPSec 信道使用傳輸級加密。這些解決方案只適用于可控制兩端的終結點的場合。

資源訪問標識

默認時，ASP.NET Web 服務并不模擬，而且要使用最低特權的 ASPNET 進程帳戶進行本地和遠程資源訪問?？梢允褂眠@個 ASPNET 進程帳戶訪問遠程網(wǎng)絡資源，如通過在數(shù)據(jù)庫服務器上創(chuàng)建鏡像的本地帳戶訪問要求進行 Windows 身份驗證的 SQL Server。

注 在 Windows Server 2003 上，默認時使用網(wǎng)絡服務帳戶運行 Web 服務。

有關使用 ASP.NET 進程帳戶進行遠程數(shù)據(jù)庫訪問的更多信息，請參閱“保護 ASP.NET 應用程序的安全”單元中“數(shù)據(jù)訪問”部分。

如果您使用模擬，適用于 Web 應用程序的問題和注意事項也適用于 Web 服務。有關更多信息，請參閱“構建安全的 ASP.NET Web 頁和控件”單元和“保護 ASP.NET 應用程序的安全”單元中的“模擬”部分。

代碼訪問安全

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

同樣，如果您從一個 ASP.NET Web 應用程序調(diào)用 Web 服務，Web 應用程序的信任級別將決定它可調(diào)用的 Web 服務的范圍。例如，一個配置為 Medium 信任的 Web 應用程序，默認時只能調(diào)用本地計算機上的 Web 服務。

有關從 Medium 和其他部分信任 Web 應用程序調(diào)用 Web 服務的更多信息，請參閱“在 ASP.NET 中使用代碼訪問安全”單元。

返回頁首

輸入驗證

與任何接受輸入數(shù)據(jù)的應用程序一樣，Web 服務也必須驗證傳給它們的數(shù)據(jù)，從而實施業(yè)務規(guī)則并防止?jié)撛诘陌踩珕栴}。用 WebMethod 屬性標記的 Web 方法是 Web 服務的入口點。Web 方法可以接受強類型的輸入?yún)?shù)或者類型選擇較寬的參數(shù)，經(jīng)常是以字符串數(shù)據(jù)的形式傳入。這通常是由 Web 服務所設計面向的使用者的類型和范圍所決定的。

強類型參數(shù)

如果您使用 .NET Framework 類型系統(tǒng)所說明的強類型參數(shù)，例如整數(shù)、雙精度、日期或者其他自定義的對象類型如 Address 或者 Employee，自動生成的 XML 架構定義 (XSD) 架構將包含數(shù)據(jù)的類型說明。使用者可以使用這種類型化說明構造發(fā)送給 Web 方法的 SOAP 請求內(nèi)適當格式化的 XML。ASP.NET 然后使用 System.Xml.Serialization.XmlSerializer 類將傳入的 SOAP 消息反序列化為公共語言運行庫 (CLR) 對象。以下示例顯示了一個 Web 方法，它接受由內(nèi)置數(shù)據(jù)類型組成的強類型輸入。

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

在前面的例子中，.NET Framework 類型系統(tǒng)將自動執(zhí)行類型檢查。為了驗證通過 name 字段提供的字符范圍，可以使用一個正則表達式。例如，以下代碼說明了如何使用 System.Text.RegularExpressions.Regex 類約束輸入字符的可能范圍，并且驗證參數(shù)長度。

if (!Regex.IsMatch(name, @"^[a-zA-Z‘.`-???′\s]{1,40}$")){// Invalid name}

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

using Employees;  // Custom namespace[WebMethod]public void CreateEmployee(Employee emp) { ... }

使用者需要了解 XSD 架構，才能調(diào)用您的 Web 服務。如果使用者是一個 .NET Framework 客戶端應用程序，則它可以直接傳入一個 Employee 對象，如下所示：

using Employees;Employee emp = new Employee();// Populate Employee fields// Send Employee to the Web servicewsProxy.CreateEmployee(emp);

而不是基于 .NET Framework 的使用者應用程序則必須根據(jù) Web 服務的負責單位所提供的架構定義，人工構造 XML 輸入。

這種強類型方法的優(yōu)點在于，.NET Framework 可以根據(jù)類型定義為您分析輸入數(shù)據(jù)并對其進行驗證。但是，在 Web 方法內(nèi)部，可能還是需要對輸入數(shù)據(jù)進行約束。例如，雖然類型系統(tǒng)確認了 Employee 對象是有效的，您可能還是需要對 Employee 字段執(zhí)行進一步驗證。可能需要驗證雇員的出生日期是否早于 18 年前?？赡苄枰褂谜齽t表達式對可用于姓名字段的字符范圍進行約束，等等。

有關約束輸入的更多信息，請參閱“構建安全的 ASP.NET Web 頁和控件”單元中的“輸入驗證”部分。

類型選擇較寬的參數(shù)

如果您使用字符串參數(shù)或者字節(jié)數(shù)組傳遞任意數(shù)據(jù)，就喪失了 .NET Framework 類型系統(tǒng)的許多好處。您必須人工分析輸入數(shù)據(jù)以對其進行驗證，因為自動生成的 WSDL 只是將參數(shù)描述為 xsd:string 類型的字符串輸入。需要如下例所示通過程序對類型、長度、格式和范圍進行檢查。

[WebMethod]public void SomeEmployeeFunction(string dateofBirth, string SSN){. . .// EXAMPLE 1: Type check the datetry{DateTime dt = DateTime.Parse(dateofBirth).Date;}// If the type conversion fails, a FormatException is throwncatch( FormatException ex ){// Invalid date}// EXAMPLE 2: Check social security number for length, format, and rangeif( !Regex.IsMatch(empSSN,@"^\d{3}-\d{2}-\d{4}$",RegexOptions.None)){// Invalid social security number}}

XML 數(shù)據(jù)

在典型的企業(yè)對企業(yè)場合中，使用者經(jīng)常需要傳遞表示業(yè)務文檔如采購定單或者銷售發(fā)票的 XML 數(shù)據(jù)。在輸入數(shù)據(jù)得到處理或者傳給下游組件之前，它的有效性必須由 Web 方法通過程序進行驗證。

客戶端和服務器必須建立一個描述 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{// Create and load a validating readerXmlValidatingReader reader = new XmlValidatingReader(xmlBookData,XmlNodeType.Element,null);// Attach the XSD schema to the readerreader.Schemas.Add("urn:bookstore-schema",@"http://localhost/WSBooks/bookschema.xsd");// Set the validation type for XSD schema.// XDR schemas and DTDs are also supportedreader.ValidationType = ValidationType.Schema;// Create and register an event handler to handle validation errorsreader.ValidationEventHandler += new ValidationEventHandler(ValidationErrors );// Process the input datawhile (reader.Read()){. . .}// Validation completed successfully}catch{. . .}}// Validation error event handlerprivate static void ValidationErrors(object sender, ValidationEventArgs args){// Error details available from args.Message. . .}

以下片段說明了使用者如何調(diào)用前面的 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ù)。

<?xml version="1.0" encoding="utf-8" ?><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 元素。

<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 服務的數(shù)據(jù)庫登錄執(zhí)行數(shù)據(jù)庫中的任意命令。SQL 注入對于使用輸入數(shù)據(jù)構造 SQL 查詢的 Web 服務而言，是一個潛在的問題。如果您的 Web 方法需要訪問數(shù)據(jù)庫，它們應該使用 SQL 參數(shù)，理想情況下是使用參數(shù)化的存儲過程進行訪問。SQL 參數(shù)可驗證輸入的類型和長度，確保輸入被當作文本而不是可執(zhí)行代碼進行處理。有關這種和其他 SQL 注入對策的更多信息，請參閱“構建安全的數(shù)據(jù)訪問”單元中的“輸入驗證”部分。

跨站點腳本攻擊

通過跨站點腳本攻擊 (XSS)，攻擊者可利用您的應用程序在客戶端執(zhí)行惡意腳本。如果您從一個 Web 應用程序中調(diào)用 Web 服務，并從 Web 服務以 HTML 數(shù)據(jù)流的形式將輸出發(fā)送回客戶端，XSS 將成為一個潛在的問題。在這種情況下，您應該對從 Web 應用程序中 Web 服務接收的輸出進行編碼，然后再將其返回給客戶端。這在您并不擁有 Web 服務而它又在 Web 應用程序的信任邊界之外時，尤其重要。有關 XSS 對策的更多信息，請參閱“構建安全的 ASP.NET Web 頁和控件”單元中的“輸入驗證”部分。

返回頁首

身份驗證

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

平臺級身份驗證

如果您可控制兩端的終結點，而且兩端的終結點都在同樣的或者可信任的域中，那么可以使用 Windows 身份驗證對調(diào)用方進行身份驗證。

基本身份驗證

可以使用 IIS 為基本身份驗證配置 Web 服務的虛擬目錄。通過這種方式，使用者必須配置代理，并提供用戶名和密碼形式的憑據(jù)。然后在每次 Web 服務通過代理請求的時候由代理傳遞它們。憑據(jù)是以明文形式傳遞的，所以應該只在 SSL 中使用基本身份驗證。

以下代碼片段說明了 Web 應用程序如何提取最終用戶所提供的基本身份驗證憑據(jù)，然后使用它們調(diào)用在 IIS 中配置為基本身份驗證的一個下游 Web 服務。

// Retrieve client‘s credentials (available with Basic authentication)string pwd = Request.ServerVariables["AUTH_PASSWORD"];string uid = Request.ServerVariables["AUTH_USER"];// Set the credentialsCredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url), // Web 服務 URL"Basic",new NetworkCredential(uid, pwd, domain) );proxy.Credentials = cache;

集成 Windows 身份驗證

可以使用 IIS 將 Web 服務的虛擬目錄配置為使用集成 Windows 身份驗證，這樣將根據(jù)客戶端和服務器的環(huán)境選擇 Kerberos 或者 NTLM 身份驗證。與基本身份驗證相比，這種方式的優(yōu)點在于，憑據(jù)不用跨網(wǎng)絡發(fā)送，從而消除了網(wǎng)絡偵聽威脅。

為了調(diào)用配置為集成 Windows 身份驗證的 Web 服務，使用者必須顯式地配置代理的 Credentials 屬性。

為了將客戶端的 Windows 安全上下文（可能來自模擬線程標記或者進程標記）傳遞給 Web 服務，可以將 Web 服務代理的 Credentials 屬性設置為 CredentialCache.DefaultCredentials，如下所示。

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

您還可以使用一個顯式的憑據(jù)集，如下所示：

CredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url), // Web 服務 URL"Negotiate",         // Kerberos or NTLMnew NetworkCredential(userName, password, domain));proxy.Credentials = cache;

如果您需要指定顯式的憑據(jù)，不用將它們硬編碼或者以明文存儲。使用 DPAPI 加密帳戶憑據(jù)并將加密數(shù)據(jù)存儲在 Web.config 中的 <appSettings> 元素中，或者一個受限的注冊表項下。

有關平臺級身份驗證的更多信息，請參閱“Microsoft patterns & practices 第 I 卷，構建安全的 ASP.NET Web 應用程序：身份驗證、授權和安全通訊”中的“Web 服務安全”部分，網(wǎng)址：http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true。

消息級身份驗證

可以使用 WSE 實現(xiàn)一種消息級身份驗證解決方案，它符合新出現(xiàn)的 WS-Security 標準。這種方法使您可通過使用 SOAP 頭以標準的方式傳遞身份驗證令牌。

注 當雙方同意使用 WS-Security 時，還必須就身份驗證令牌的精確格式取得一致。

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

用戶名和密碼

您可以在 SOAP 頭中發(fā)送用戶名和密碼憑據(jù)。但是，因為這些憑據(jù)是通過明文發(fā)送的，為了防止網(wǎng)絡偵聽威脅，這種方法只應與 SSL 結合使用。憑據(jù)是作為 SOAP 頭中 <Security> 元素的一部分發(fā)送的，如下所示。

<wsse:Securityxmlns: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ā)送明文的密碼。摘要是一種 UTF8 編碼密碼的 Base64 編碼 SHA1 散列值。但是，除非這種方法是在安全信道使用，數(shù)據(jù)仍然可被擁有網(wǎng)絡監(jiān)視軟件的攻擊者所截獲，并再次用來獲取對 Web 服務的已經(jīng)過身份驗證的訪問權限。為了幫助應對這種重放攻擊威脅，可以將摘要與 nonce 值和創(chuàng)建時間戳結合使用。

帶有 nonce 值和時間戳的用戶名和密碼摘要

這種方法中，摘要是 nonce 值、創(chuàng)建時間戳和密碼的 SHA1 散列值，如下所示。

digest = SHA1(nonce + creation timestamp + password)

這種方法中，Web 服務必須維護一個 nonce 值表，并拒絕任何包含著重復 nonce 值的消息。雖然這種方法有助于保護密碼，并為防止重放攻擊提供基礎，但是在計算到期時間上受使用者和提供者之間的時鐘同步問題影響很大，而且它無法防止攻擊者捕獲消息、修改 nonce 值然后將消息重放到 Web 服務。為了解決這種威脅，消息必須進行數(shù)字簽名。使用 WSE，您可以使用自定義令牌或者 X.509 證書對消息進行數(shù)字簽名。這樣可根據(jù)公鑰和私鑰對提供防篡改和身份驗證。

Kerberos 票證

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

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

X.509 證書

您還可以通過將 X.509 證書作為身份驗證令牌發(fā)送提供身份驗證。

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

有關以上方法的更多信息，請參閱 WSE 中附帶的示例。

應用程序級身份驗證

您可以通過在應用程序中使用自定義 SOAP 頭設計和構建自己的自定義身份驗證。在此之前，需要查看平臺和 WSE 提供的功能，以確定是否可以使用任何功能。如果您必須使用自定義身份驗證機制，而且需要使用加密技術，那么應該使用 System.Security.Cryptography 命名空間公開的標準加密算法。

返回頁首

授權

在身份驗證之后，您可以根據(jù)調(diào)用方的身份或者角色成員資格，限制調(diào)用方只擁有 Web 服務所公開功能的一個子集。您可以對服務的終結點（在 .asmx 文件級）、單獨的 Web 方法或者 Web 方法中特定功能的訪問進行限制。

Web 服務終結點的授權

如果 Web 服務配置為集成 Windows 身份驗證，可以在您的 Web 服務 (.asmx) 文件上根據(jù)原始調(diào)用方的安全上下文配置 NTFS 權限以控制訪問。這種授權是通過 ASP.NET FileAuthorizationModule 執(zhí)行的，無需模擬。

無論身份驗證類型如何，都可以使用 ASP.NET UrlAuthorizationModule 控制對 Web 服務 (.asmx) 文件的訪問。通過在 Machine.config 或者 Web.config 中的 <authorization> 元素中添加 <allow> 和 <deny> 元素可以進行這種配置。

有關兩種形式的授權的更多信息，請參閱“保護 ASP.NET 應用程序的安全”單元中的“授權”部分。

Web 方法授權

可以使用聲明性的主體權限要求，根據(jù)調(diào)用方的身份或者角色成員資格控制對單獨 Web 方法的訪問。 調(diào)用方的身份和角色成員資格是由與當前 Web 請求相關的主體對象（通過 HttpContext.User 訪問）維護的。

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

有關主體權限要求的更多信息，請參閱“構建安全的 ASP.NET Web 頁和控件”單元中的“授權”部分。

編程授權

可以通過調(diào)用 Web 方法中的 IPrincipal.IsInRole，使用命令性權限檢查或者顯式的角色檢查實現(xiàn)細致的授權邏輯，如下所示。

// This assumes non-Windows authentication. With Windows authentication// cast the User object to a WindowsPrincipal and use Windows groups as// role namesGenericPrincipal user = User as GenericPrincipal;if (null != user){if ( user.IsInRole(@"Manager") ){// User is authorized to perform manager functionality}}

返回頁首

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

如果 Web 服務請求或者響應消息需要傳遞敏感應用程序數(shù)據(jù)（例如，信用卡號碼、雇員詳細情況等等）的話，就必須解決在中間應用程序節(jié)點受到的網(wǎng)絡偵聽或者信息泄漏的威脅。

在一個封閉環(huán)境中，您可控制兩端的終結點，因此可以使用 SSL 或者 IPSec 提供傳輸層加密。在其他環(huán)境中并且消息是通過中間應用程序節(jié)點路由的，因此需要消息級解決方案。WS-Security 標準以 WWW 聯(lián)合會 (W3C) XML 加密標準為基礎定義了一個機密服務，可以用來在傳輸 SOAP 消息之前加密其部分或者全部 SOAP 消息。

XML 加密

您可以用三種不同的方式加密所有或者部分 SOAP 消息：

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

在此方法中，使用者使用 X.509 證書的公鑰部分加密 SOAP 消息。該消息將只能被擁有對應私鑰的服務解密。

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

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

如果您使用用戶存儲區(qū)，則必須加載 Web 服務進程帳戶的用戶配置文件。如果您使用默認 ASPNET 最低特權本地帳戶運行 Web 服務，.NET Framework 的 1.1 版需要加載此帳戶的用戶配置文件，從而使用戶密鑰存儲區(qū)變?yōu)榭稍L問狀態(tài)。

對于使用 .NET Framework 1.0 版構建的 Web 服務，并不加載 ASPNET 用戶配置文件。這種情況下，有兩種選擇。

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

有關更多信息，請參閱 WSE 文檔中的“Managing X.509 Certificates,”、“Encrypting a SOAP Message Using an X.509 Certificate,”和“Decrypting a SOAP Message Using an X.509 Certificate”部分。

使用共享密鑰的對稱加密

使用對稱加密時，Web 服務及其使用者共享一個密鑰，對 SOAP 消息進行加密和解密。這種加密比不對稱加密要快，雖然使用者和服務的提供者必須使用某種帶外機制共享密鑰。

有關更多信息，請參閱 WSE 文檔中的“Encrypting a SOAP Message Using a Shared Key”和“Decrypting a SOAP Message Using a Shared Key”部分。

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

您還可以使用 WSE 定義一個自定義二進制令牌，封裝用來加密和解密消息的自定義安全憑據(jù)。您的代碼需要兩個類。發(fā)送器類必須從 BinarySecurityToken 類派生，它用于封裝自定義安全憑據(jù)和加密消息。接收類必須從 DecryptionkeyProvider 類中派生，它用于檢索密鑰和解密消息。

有關更多信息，請參閱 WSE 文檔中的“Encrypting a SOAP Message Using a Custom Binary Security Token”和“Decrypting a SOAP Message Using a Custom Binary Security Token”部分。

加密部分消息

默認時，WSE 將加密整個 SOAP 體，并不加密 SOAP 頭信息。但是，也可以使用 WSE 通過編程加密和解密消息的某些部分。

有關更多信息，請參閱 WSE 文檔中的“Specifying the Parts of a SOAP Message that are Signed or Encrypted”部分。

返回頁首

參數(shù)操作

與 Web 服務相關的參數(shù)操作，指的是這樣的威脅：在消息請求或者響應在使用者和服務之間傳輸途中，攻擊者能夠以某種方式修改消息負載。

為了解決這種威脅，您可以對 SOAP 消息進行數(shù)字簽名，以允許消息的接收者使用加密技術驗證消息自數(shù)字簽名之后是否沒有被更改。有關更多信息，請參閱 WSE 文檔中的“Digitally Signing a SOAP Message”部分。

返回頁首

異常管理

返回給使用者的異常細節(jié)應該只包含最低級別的信息，不能暴露任何內(nèi)部實現(xiàn)細節(jié)。例如，考慮如下的允許傳播給使用者的系統(tǒng)異常。

System.Exception: User not in managers roleat EmployeeService.employee.GiveBonus(Int32 empID, Int32 percentage) in c:\inetpub\wwwroot\employeesystem\employee.asmx.cs:line 207

上面所示的異常細節(jié)將目錄結構和其他細節(jié)暴露給服務的使用者。這一信息可能被惡意用戶用來記錄虛擬目錄路徑，從而幫助進行進一步的攻擊。Web 服務可引發(fā)三種類型的異常：

無論異常類型如何，異常細節(jié)都會使用標準 SOAP 的 <Fault> 元素傳播到客戶端。用 ASP.NET 構建的客戶端和 Web 服務不會直接分析 <Fault>元素，而是應該統(tǒng)一處理 SoapException 對象。這樣客戶端可以設置可捕獲 SoapException 對象的 try 塊。

注 如果從一個自定義的 HTTP 模塊引發(fā) SoapException 異常，它不會自動地序列化為 SOAP<Fault> 元素。這種情況下，必須人工創(chuàng)建 SOAP<Fault>。

使用 SoapException

以下代碼顯示了一個簡單的 Web 方法，其中應用程序邏輯的驗證失敗了，因此生成了一個異常。發(fā)送給客戶端的錯誤信息非常少。在本例中，為客戶端提供了可用于調(diào)用支持的幫助桌面引用。在 Web 服務器上，將幫助桌面引用的詳細錯誤說明記錄起來，以幫助進行問題的診斷。

using System.Xml;using System.Security.Principal;[WebMethod]public void GiveBonus(int empID, int percentage){// Only managers can give bonuses// This example uses Windows authenticationWindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);if( wp.IsInRole(@"Domain\Managers")){// User is authorized to give bonus. . .}else{// Log error details on the server. For example://    "DOMAIN\Bob tried to give bonus to Employee Id 345667;//     Access denied because DOMAIN\Bob is not a manager."http:// Note: User name is available from wp.Identity.Name// Return minimal error information to client using a SoapExceptionXmlDocument doc = new XmlDocument();XmlNode detail = doc.CreateNode(XmlNodeType.Element,SoapException.DetailElementName.Name,SoapException.DetailElementName.Namespace);// This is the detail part of the exceptiondetail.InnerText = "User not authorized to perform requested operation";throw new SoapException("Message string from your Web 服務",SoapException.ServerFaultCode,Context.Request.Url.AbsoluteUri, detail, null );}}

處理可能出現(xiàn)的 SoapException 的使用方代碼如下所示：

try{EmployeeService service = new EmployeeService();Service.GiveBonus(empID,percentage);}catch (System.Web.Services.Protocols.SoapException se){// Extract custom message from se.Detail.InnerTextConsole.WriteLine("Server threw a soap exception" + se.Detail.InnerText );}

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

ASP.NET Web 應用程序一般處理允許傳播超出 Global.asax. 中的 Application_Error 事件處理程序中方法邊界的應用程序級異常。這種功能在 Web 服務中是沒有的，因為 Web 服務的 HttpHandler 會在異常到達其他處理程序之前捕獲它。

如果需要應用程序級異常處理，請創(chuàng)建自定義 SOAP 擴展對其進行處理。有關更多信息，請參閱 MSDN 文章“Altering the SOAP Message using SOAP Extensions”，位于 .NET Framework SDK 的“Building Applications”部分中，網(wǎng)址是：http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&DisplayLang=en。

返回頁首

審核和日志記錄

通過 Web 服務，可以使用平臺級功能或者在 Web 方法實現(xiàn)中使用自定義代碼，以審核和記錄活動細節(jié)以及事務。

可以開發(fā)使用 System.Diagnostics.EventLog 類將操作記錄到 Windows 事件日志的代碼。從 Web 服務使用這個類的權限要求和技術與 Web 應用程序相同。有關更多信息，請參閱“構建安全的 ASP.NET 頁和控件”單元中的“審核和日志記錄”部分。

返回頁首

代理注意事項

如果使用 WSDL 自動生成一個代理類與 Web 服務通信，應該驗證所生成的代碼和服務終結點，確保您是在與希望的 Web 服務而非被欺騙的服務通信。如果遠程服務器上的 WSDL 文件未被保護，惡意用戶就有可能篡改文件，改變終結點地址，從而可能影響您生成的代理代碼。

具體而言，查看 .wsdl 文件中的 <soap:address> 元素，驗證它是否指向期望的位置。如果通過 Add Web Reference 對話框使用 Visual Studio .NET 添加 Web 引用，向下滾動，查看服務終結點。

最后，無論是使用 Visual Studio.NET 添加 Web 引用還是使用 Wsdl.exe 手工生成代理代碼，都要仔細檢查代理代碼，尋找任何可疑的代碼。

注 可以將 Web 服務代理的 URL Behavior 屬性設置為Dynamic，這樣就可在 Web.config 中指定終結點地址了。

返回頁首

代碼訪問安全注意事項

代碼訪問安全可限制 Web 服務代碼可訪問的資源和可執(zhí)行的操作。ASP.NET Web 服務要受 ASP.NET 代碼訪問安全策略的約束，該策略是通過 Web 服務的 <trust> 元素進行配置的。

調(diào)用 Web 服務的 .NET Framework 使用方代碼必須由代碼訪問安全策略授予 WebPermission 權限。WebPermission 的準確狀態(tài)決定了可調(diào)用 Web 服務的范圍。例如，可以約束代碼使其只能調(diào)用本地 Web 服務或者指定服務器上的服務。

如果使用方代碼有完全信任，它被授予無限的 WebPermission 權限，允許您調(diào)用任何 Web 服務。部分信任的使用方代碼有以下限制：

有關從部分信任 Web 應用程序調(diào)用 Web 服務的更多信息，請參閱“在 ASP.NET 中使用代碼訪問安全”單元。有關 WebPermission 的更多信息，請參閱“代碼訪問安全實踐”單元中的“Web 服務”部分。

返回頁首

部署注意事項

您可選擇的安全措施范圍有多大，很大程度上取決于您的 Web 服務要覆蓋的特定部署場景。如果構建的應用程序是在 intranet 中使用 Web 服務，則您可隨意選擇的安全措施和技術的范圍是最大的。但是，如果您的 Web 服務是可以跨 Internet 公開訪問的，您的選擇范圍就大受限制。本部分將敘述不同的部署情況對本單元中前面討論的 Web 服務保護方法適用性的影響。

Intranet 部署

因為您可控制使用者應用程序、服務和平臺，Intranet 通常能提供最大范圍的保護 Web 服務安全的選擇。

在 Intranet 場合中，您通?？蓮娜康纳矸蒡炞C和安全通信選項中進行選擇。例如，如果使用者和服務在同樣的域或者信任域中，可以決定使用 Windows 身份驗證。您可以指定客戶端應用程序的開發(fā)人員設置客戶端代理的憑據(jù)屬性，將用戶的 Windows 憑據(jù)傳遞給 Web 服務。

Intranet 通信經(jīng)常是通過專用網(wǎng)絡傳遞，有一定的安全性。如果這種安全性不夠，可以決定通過使用 SSL 加密通信。您還可以使用消息級安全，并在客戶端和服務器上都安裝 WSE，以處理兩端的安全，而這對于應用程序而言是透明的。WSE 支持身份驗證、數(shù)字簽名和加密。

Extranet 部署

在 Extranet 情況下，可能需要跨 Internet 對數(shù)目有限的一些合作伙伴公開 Web 服務。用戶群體依然是已知的、可預測的，還可能使用托管客戶端應用程序，雖然它們來自不同的獨立的環(huán)境。在這種情況下，需要一種適合雙方而且不依賴于信任域的身份驗證機制。

如果雙方都可獲得帳戶信息，可以使用基本身份驗證。如果您使用基本身份驗證，要確保通過使用 SSL 保護好憑據(jù)。

注 SSL 只保護跨網(wǎng)絡傳輸?shù)膽{據(jù)。如果惡意用戶成功地在客戶端機器本地安裝了代理工具（如 sslproxy），并在通過 SSL 將調(diào)用轉發(fā)給 Web 服務之前進行截獲，則 SSL 是無法進行保護的。

在 Extranet 中可以采取的另一種選擇，是使用 IIS 客戶端證書身份驗證代替?zhèn)鬟f顯式的憑據(jù)。在這種情況下，調(diào)用方應用程序必須在調(diào)用時提供有效證書。Web 服務使用證書對調(diào)用方進行身份驗證和對操作進行授權。有關更多信息，請參閱 MSDN 文章“構建安全的 ASP.NET 應用程序”（網(wǎng)址是 http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch06.asp）中的“Extranet 安全”部分。

Internet 部署

如果您要對大量 Internet 使用者公開 Web 服務，而且需要進行身份驗證，可以考慮的選擇是充分進行約束。任何形式的平臺級身份驗證都不可能適合，因為使用者無法具有正確的域帳戶以對應其憑據(jù)。當大量的客戶端證書對目標 IIS Web 服務器（或者在它之前的 ISA Server）而言必須已知時，使用 IIS 客戶端證書身份驗證和傳輸層加密 (SSL) 也存在問題。這樣，只剩下消息級和應用程序級身份驗證和授權是最可能的選擇了。服務的使用者所傳遞的憑據(jù)（以用戶名、密碼、證書、Kerberos 票證或者自定義令牌的形式）可以被 Web 服務基礎結構 (WSE) 透明地進行驗證，或者在目標服務中通過程序進行驗證。很難控制客戶端證書的規(guī)模。密鑰管理（頒發(fā)和撤消）就成問題了。而且，基于證書的身份驗證是資源密集型的，因此在有大量客戶端時它會受可伸縮性問題的困擾。

SSL 通常可提供網(wǎng)絡流量的加密（僅限于服務器端證書），但是也可以用消息級加密進行補充。

使用客戶端證書，雖然從安全角度來看有其優(yōu)點，但是經(jīng)常會在用戶數(shù)目很大時遇到問題。您必須仔細地管理證書，并且考慮應該如何將證書傳遞到客戶端，還有更新、撤消等等事情。由于存在處理開銷或者大規(guī)模大工作量的 Web 服務的加密/解密和證書驗證，Internet 場景中的另一個潛在問題是解決方案的總可伸縮性。

返回頁首

小結

WS-Security 是 Web 服務安全方面新出現(xiàn)的標準。該標準定義了通過使用 SOAP 頭以標準方式傳遞安全令牌進行身份驗證的各種選項。令牌可包括用戶名、密碼憑據(jù)、Kerberos 票證、X.509 證書或者自定義令牌。WS-Security 還解決了消息私密性和完整性問題?？梢约用苷麄€或者部分消息以提供私密性，對其進行數(shù)字簽名以提供完整性。

在 Intranet 場景中，您控制著兩端的終結點，可以使用平臺級（如 Windows 身份驗證）的安全選項。在更復雜的場景中，您無法控制兩端的終結點，消息的路由通過中間應用程序節(jié)點，就需要消息級解決方案了。下面的部分“其他資源”列出了可用來跟蹤新出現(xiàn)的 WS-Security 標準和相關 WSE 工具集的 Web 站點，這樣您可構建符合此標準和其他新出現(xiàn)的 Web 服務標準的解決方案。