欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

本單元概要

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

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

返回頁(yè)首

目標

通過(guò)本單元可以：

返回頁(yè)首

適用范圍

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

返回頁(yè)首

如何使用本單元

要想充分利用本單元：

本頁(yè)內容

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

返回頁(yè)首

概述

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

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

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

返回頁(yè)首

威脅與對策

為了構建安全的 Web 服務(wù)，需要了解相關(guān)的威脅。針對 Web 服務(wù)的最大威脅主要有：

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

圖 1. 主要的 Web 服務(wù)威脅

未授權訪(fǎng)問(wèn)

提供敏感或者受限信息的 Web 服務(wù)應該對其調用方進(jìn)行身份驗證和授權。脆弱的身份驗證和授權會(huì )被人利用，以獲取對敏感信息和操作的未授權訪(fǎng)問(wèn)。

缺陷

可能通過(guò) Web 服務(wù)導致未授權訪(fǎng)問(wèn)的缺陷包括：

對策

可以使用以下對策防止未授權的訪(fǎng)問(wèn)：

參數操作

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

缺陷

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

對策

可以使用以下對策防止參數操作：

網(wǎng)絡(luò )偵聽(tīng)

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

缺陷

導致網(wǎng)絡(luò )偵聽(tīng)可能成功實(shí)施的缺陷包括：

對策

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

配置數據的泄漏

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

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

第二種是，由于不適當的異常處理，Web 服務(wù)可能泄漏對攻擊者有用的敏感的內部實(shí)現細節。

缺陷

可能導致配置數據泄漏的缺陷包括：

對策

可以使用以下對策防止有害的配置數據泄漏：

消息重放

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

缺陷

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

攻擊

最常見(jiàn)的消息重放攻擊類(lèi)型包括：

對策

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

返回頁(yè)首

設計注意事項

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

身份驗證要求

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

私密性和完整性要求

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

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

資源訪(fǎng)問(wèn)標識

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

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

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

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

代碼訪(fǎng)問(wèn)安全

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

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

有關(guān)從 Medium 和其他部分信任 Web 應用程序調用 Web 服務(wù)的更多信息，請參閱“在 ASP.NET 中使用代碼訪(fǎng)問(wèn)安全”單元。

返回頁(yè)首

輸入驗證

與任何接受輸入數據的應用程序一樣，Web 服務(wù)也必須驗證傳給它們的數據，從而實(shí)施業(yè)務(wù)規則并防止潛在的安全問(wèn)題。用 WebMethod 屬性標記的 Web 方法是 Web 服務(wù)的入口點(diǎn)。Web 方法可以接受強類(lèi)型的輸入參數或者類(lèi)型選擇較寬的參數，經(jīng)常是以字符串數據的形式傳入。這通常是由 Web 服務(wù)所設計面向的使用者的類(lèi)型和范圍所決定的。

強類(lèi)型參數

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

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

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

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

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

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

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

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

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

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

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

類(lèi)型選擇較寬的參數

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

[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 數據

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

客戶(hù)端和服務(wù)器必須建立一個(gè)描述 XML 的架構，并對其達成一致。以下代碼片段說(shuō)明了一個(gè) Web 方法如何使用 System.Xml.XmlValidatingReader 類(lèi)驗證輸入數據，在此例中，輸入數據描述了一個(gè)簡(jiǎn)單的定單。請注意 XML 數據是通過(guò)一個(gè)簡(jiǎn)單的字符串參數傳遞的。

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. . .}

以下片段說(shuō)明了使用者如何調用前面的 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));

前面的例子使用以下的簡(jiǎn)單 XSD 架構驗證輸入數據。

<?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 架構中可以使用的其他復雜的元素定義，可以進(jìn)一步約束單獨的 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>

有關(guān)更多信息，請參閱 Microsoft 知識庫文章：

SQL 注入式攻擊

SQL 注入使攻擊者可使用 Web 服務(wù)的數據庫登錄執行數據庫中的任意命令。SQL 注入對于使用輸入數據構造 SQL 查詢(xún)的 Web 服務(wù)而言，是一個(gè)潛在的問(wèn)題。如果您的 Web 方法需要訪(fǎng)問(wèn)數據庫，它們應該使用 SQL 參數，理想情況下是使用參數化的存儲過(guò)程進(jìn)行訪(fǎng)問(wèn)。SQL 參數可驗證輸入的類(lèi)型和長(cháng)度，確保輸入被當作文本而不是可執行代碼進(jìn)行處理。有關(guān)這種和其他 SQL 注入對策的更多信息，請參閱“構建安全的數據訪(fǎng)問(wèn)”單元中的“輸入驗證”部分。

跨站點(diǎn)腳本攻擊

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

返回頁(yè)首

身份驗證

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

平臺級身份驗證

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

基本身份驗證

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

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

// 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 服務(wù) URL"Basic",new NetworkCredential(uid, pwd, domain) );proxy.Credentials = cache;

集成 Windows 身份驗證

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

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

為了將客戶(hù)端的 Windows 安全上下文（可能來(lái)自模擬線(xiàn)程標記或者進(jìn)程標記）傳遞給 Web 服務(wù)，可以將 Web 服務(wù)代理的 Credentials 屬性設置為 CredentialCache.DefaultCredentials，如下所示。

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

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

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

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

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

消息級身份驗證

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

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

WSE 可使用和支持以下類(lèi)型的身份驗證令牌：

用戶(hù)名和密碼

您可以在 SOAP 頭中發(fā)送用戶(hù)名和密碼憑據。但是，因為這些憑據是通過(guò)明文發(fā)送的，為了防止網(wǎng)絡(luò )偵聽(tīng)威脅，這種方法只應與 SSL 結合使用。憑據是作為 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>

用戶(hù)名和密碼摘要

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

帶有 nonce 值和時(shí)間戳的用戶(hù)名和密碼摘要

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

digest = SHA1(nonce + creation timestamp + password)

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

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 證書(shū)

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

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

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

應用程序級身份驗證

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

返回頁(yè)首

授權

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

Web 服務(wù)終結點(diǎn)的授權

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

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

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

Web 方法授權

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

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

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

編程授權

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

// 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}}

返回頁(yè)首

敏感數據

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

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

XML 加密

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

使用 X.509 證書(shū)的不對稱(chēng)加密

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

Web 服務(wù)必須能夠訪(fǎng)問(wèn)相關(guān)的私鑰。默認時(shí)，WSE 會(huì )在本地機器存儲區中搜索 X.509 證書(shū)?？梢允褂?Web.config 中的 <x509> 配置元素將存儲位置設置為當前用戶(hù)存儲區，如下所示。

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

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

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

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

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

使用共享密鑰的對稱(chēng)加密

使用對稱(chēng)加密時(shí)，Web 服務(wù)及其使用者共享一個(gè)密鑰，對 SOAP 消息進(jìn)行加密和解密。這種加密比不對稱(chēng)加密要快，雖然使用者和服務(wù)的提供者必須使用某種帶外機制共享密鑰。

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

使用自定義二進(jìn)制令牌的對稱(chēng)加密

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

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

加密部分消息

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

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

返回頁(yè)首

參數操作

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

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

返回頁(yè)首

異常管理

返回給使用者的異常細節應該只包含最低級別的信息，不能暴露任何內部實(shí)現細節。例如，考慮如下的允許傳播給使用者的系統異常。

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

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

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

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

使用 SoapException

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

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 服務(wù)",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){// 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 服務(wù)中是沒(méi)有的，因為 Web 服務(wù)的 HttpHandler 會(huì )在異常到達其他處理程序之前捕獲它。

如果需要應用程序級異常處理，請創(chuàng )建自定義 SOAP 擴展對其進(jìn)行處理。有關(guān)更多信息，請參閱 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。

返回頁(yè)首

審核和日志記錄

通過(guò) Web 服務(wù)，可以使用平臺級功能或者在 Web 方法實(shí)現中使用自定義代碼，以審核和記錄活動(dòng)細節以及事務(wù)。

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

返回頁(yè)首

代理注意事項

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

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

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

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

返回頁(yè)首

代碼訪(fǎng)問(wèn)安全注意事項

代碼訪(fǎng)問(wèn)安全可限制 Web 服務(wù)代碼可訪(fǎng)問(wèn)的資源和可執行的操作。ASP.NET Web 服務(wù)要受 ASP.NET 代碼訪(fǎng)問(wèn)安全策略的約束，該策略是通過(guò) Web 服務(wù)的 <trust> 元素進(jìn)行配置的。

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

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

有關(guān)從部分信任 Web 應用程序調用 Web 服務(wù)的更多信息，請參閱“在 ASP.NET 中使用代碼訪(fǎng)問(wèn)安全”單元。有關(guān) WebPermission 的更多信息，請參閱“代碼訪(fǎng)問(wèn)安全實(shí)踐”單元中的“Web 服務(wù)”部分。

返回頁(yè)首

部署注意事項

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

Intranet 部署

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

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

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

Extranet 部署

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

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

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

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

Internet 部署

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

SSL 通?？商峁┚W(wǎng)絡(luò )流量的加密（僅限于服務(wù)器端證書(shū)），但是也可以用消息級加密進(jìn)行補充。

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

返回頁(yè)首

小結

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

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