如果 XML Web 服務正在 Internet Information Server (IIS) 上運行，那么我們就有必要提及一種能免費得到的非常有用的報告類型。即，為所有傳入的 HTTP 請求（包括對您服務的請求）進行的 IIS 日志記錄。您可以使用 IIS 日志中提供的信息來改進自己的報告。
最后，實施了審核及適當的報告方法后，您需要使用某種機制以發現所報告的問題。這就是監視。
可以以不同級別進行監視。當然，定期手動查看報告是監視 XML Web 服務的使用情況的一種方式，但是還應檢查事件日志中已報告的錯誤，使用性能監視日志，并利用可以監視 Web 服務器停機時間的多種工具中的一種。性能監視對于檢測攻擊可能是非常關鍵的。幸好，與 IIS 關聯的大量性能計數器可以為檢測問題提供許多重要的統計數據。
您可能還希望為 XML Web 服務創建自己的性能計數器。有關創建您自己的性能計數器的詳細信息，請參閱 Performance Monitoring（英文）。為了確保引起您對異常情況的特殊關注，應以某種形式通知您正在發生的事件，這點是非常重要的?？梢栽诋惓Ｊ录l生時，利用性能監視警報發送彈出式消息，或運行某個程序。圖 1 顯示的性能監視警報會監視未完成的 IIS ISAPI 請求的數量，以及當前隊列中的 ASP 請求的數量。
如果不對可能發生的問題采取一些措施，則對濫用的操作進行審核、報告和監視不會有任何用處。拒絕服務攻擊可能會被定義到特定的 IP 地址，這意味著您可能需要在路由器中過濾來自該地址的請求。但是，拒絕服務攻擊或電子欺騙攻擊可能與 XML Web 服務的特定用戶相關。您必須能夠在這種問題發生時禁用帳戶。完成此操作可能僅需在 Microsoft® Active Directory™ 中禁用 Windows 用戶帳戶?；蛘?，如果使用的是自己設計的身份驗證方式，則意味著必須在用戶記錄中添加一個可以表示禁用帳戶的狀態字段。您還應確認 XML Web 服務的用戶同意“服務條款”文檔，該文檔指明在何種情況下您可以刪除或禁用他們的帳戶。
定義接口
與其他 Web 應用程序相比，XML Web 服務器應用程序的一個主要優點就是很好地定義了傳遞到您的應用程序的整個 XML 架構。對于應用程序設計人員和開發人員來說，這意味著您已經知道 XML Web 服務所必須處理的數據具有有效的格式。如果接收的數據格式不正確，那么 Microsoft® SOAP Toolkit 2.0 或 .NET 框架之類的工具將過濾出該請求，這樣您就不必為此擔心了。
例如，您不必分析日期輸入的語法是否有效。日期必須具有有效的 XSD 格式，否則該請求會被丟棄。您可能需要利用結構驗證，因此不要隱藏字符串變量中的結構。利用 XML 的能力和靈活性可以全面描述發送和接收的數據。
不可見的服務器
黑客攻擊您的系統時，首先尋找的是信息。此 Web 站點是駐留在 Windows 中還是駐留在其他系統中？是否正在運行 Active Server Pages？是否安裝了 Index Server？是否安裝了已知的易受攻擊的組件？是否安裝了已知的易受攻擊的 CGI 應用程序？主機是否正在運行 Microsoft SQL Server？我是否可以對此服務器進行分布式 COM (DCOM) 調用？
對于不希望受到攻擊的站點，即使非常聰明的 Internet 用戶也應該無法回答上述任何問題。黑客對您的系統了解得越少，對平臺的了解也越少，就越難在您的服務器上找到問題。
例如，試想一下，如果黑客只知道 XML Web 服務的 URL 為“http://www.coldrooster.com/ssf/account.asp”，他們能了解什么呢。由于此 URL 的擴展名為 .ASP，他們可以假設這是一臺運行了 Active Server Pages 的 Windows 計算機。根據黑客對 Internet Information Server 的默認配置的了解，他們已具有足夠的信息對大量的未正確配置的弱點進行攻擊。他們可對配置方法進行大量的、很可能有效的假設，并用這些假設來刺探計算機。
如果 URL 為“http://www.coldrooster.com/ssf/account/”，情況又會怎樣呢？在這種情況下，黑客得不到任何服務器所用操作系統的信息，也無從假設系統的配置。將虛擬目錄級的請求映射到某個特定的 ASP 頁是一個非常小的配置選項，但能為服務器提供很多保護。
熟悉基本 HTTP 協議的用戶可能注意到 HTTP 標頭特別指明了正在使用的 Web 服務器類型。是的，這是另一種確定計算機上操作系統的更為復雜的方法，但是也可以編寫 ISAPI 過濾器來刪除或替換此標頭。有關如何進行這種操作的信息，請參閱 Developing ISAPI Filters（英文）,以及 IIS 程序員指南中的 SF_NOTIFY_SEND_RESPONSE（英文）通知。服務器上運行的基礎系統越難辨認，黑客編寫的用于在 Internet 上查找某種類型計算機的腳本失敗的可能性就越大。
但是操作系統本身并不是唯一的弱點。您創建的 ASP 頁在后端執行 SQL 查詢并拋出異常時，會執行什么操作？您是否將異常信息返回給用戶瀏覽器？這樣不僅指出了 Web 服務器平臺，還指出了數據庫平臺。除此之外，它還可以使用戶了解您正在進行的特定 SQL 查詢，并為他們提供信息，使其了解如何更改要輸入到窗體中的內容以得到他們不應有權訪問的信息。
出現其他 COM 異常情況怎么辦？如果將異常信息傳播給用戶，黑客將會知道您的計算機上安裝了哪些 COM 組件。如果此 COM 對象是第三方 DLL，則黑客可以得到它的一個副本，并竭盡全力搜索可能存在的所有弱點。這至少使黑客有機會了解服務器上可能存在的問題。
同樣，黑客可能會利用觸發 COM 異常這一事實來阻塞服務器。黑客意識到多數異常代碼路徑未經充分測試，且常常是資源泄露或變得更糟的起因。要避免出現這種情況，服務器上的代碼應能捕獲所有異常情況，并且應該只返回普遍性的錯誤。對于 XML Web 服務，您應返回幾乎不帶有平臺信息的 SOAP 錯誤。您可能希望以某種方式將數據連同 ID 一起返回給用戶以便將錯誤與審核日志中的記錄進行比較，但是，請將錯誤詳細信息放在審核日志中而不是放在返回的 SOAP 錯誤中。建議應用程序設計人員創建自己的應用程序的 SOAP 錯誤架構，同時提供一個非常短的選項列表，并且僅返回此列表上的錯誤。調用 XML Web 服務的客戶端不必知道有關 SQL 查詢異常的詳細信息，他們只需要知道出現了 SOAP 服務器錯誤。
如果正在使用 Microsoft® SOAP Toolkit 2.0，可以在 COM 對象上實現 ISoapError 接口以返回您希望返回的確切的 SOAP 錯誤,而不是一般的工具包錯誤。一般的工具包錯誤可以提供大量的、有關錯誤出現時在服務器上所發生情況的信息。在開發階段，工具包錯誤對于調試來說是很有用的，但是它們在產品服務器上不應出現。他們可以為黑客提供大量的、具有潛在破壞性的信息。
