XML Web 服務的用戶需要知道您的服務所發送和接收的 SOAP 消息的格式，以及您的服務的終點位置。這就足夠了。任何其他信息都只會為潛在的黑客提供攻擊手段以毀壞您的系統。要進行自我保護，應限制返回與平臺有關的信息，并消除計算機上的多余內容，包括刪除任何有助于他人識別您的系統的默認虛擬目錄或腳本映射。
開發問題
對黑客來說，服務器的脆弱性與服務器上運行的代碼質量是成反比的。它包括基礎系統（操作系統、Web 服務器和正在使用的 SOAP 工具）的質量，以及為特定應用程序編寫的代碼的質量。還可能包括服務器上運行的所有其他代碼，即使該代碼不是應用程序的一部分。但是從開發人員的角度而言，我們希望考慮我們能控制的問題，以及能執行哪些特殊的操作以保證代碼的高質量，避免增加 XML Web 服務和服務器上正在運行的其他所有應用程序的脆弱性。
緩沖區溢出
服務器上最可怕的攻擊類型是遠程用戶可以執行惡意代碼導致系統完全破壞的攻擊。大多數此類攻擊都是由于緩沖區溢出錯誤造成的。這種錯誤的典型示例是：在 C 代碼中為某本地變量分配了固定長度，然后該代碼將 HTTP 請求中的信息復制到該變量中。如果您認為請求中的數據不會比您設定的值大，而對您的服務器的惡意請求可以超過該值，并導致其發送的數據在寫入到已分配的緩沖區時超出末端。對于本地變量，緩沖區存儲在堆棧中，而堆棧中還存儲了當前函數結束時要返回的代碼地址。通過寫入時超出本地變量緩沖區的末端，黑客可以覆蓋返回地址并使函數返回到他想要的任何地址，包括 Windows CreateProcess 函數的地址。要傳遞到 CreateProcess 函數的參數也會存儲在堆棧上，如果黑客覆蓋了存儲這些參數的位置，則可以有效啟動服務器上他們想要啟動的任何應用程序。
要避免這類攻擊，請不要對從請求中讀取的數據做任何假設，然后確保緩沖區的處理代碼中沒有錯誤。對于 C/C++ 程序員，應對以下函數格外小心：strcpy、strcat、memcpy、gets、sprintf、scanf 以及所有這些函數的變體（如 lstrcpy、wcscpy、CopyMemory 等等）。請注意 strncpy 函數及其他“n”函數只是略好一些，因為在這些方案中長度變量常常是由程序決定的，而且仍有可能覆蓋固定長度的緩沖區。“n”函數中的長度參數應根據輸出緩沖區的大小而定，而非傳入字符串的大小。如果要使用這些函數，請使用“n”版本并從堆中動態分配您的緩沖區以避免可能的堆棧溢出。另外，Microsoft® Visual Studio .NET C 編譯器支持新的 /GS 開關，該開關可使代碼不會出現許多常見的緩沖區溢出問題。
利用 .NET 框架和管理代碼，可以消除大多數潛在的緩沖區溢出問題。Microsoft 設計 .NET 框架時，意識到了垃圾回收的好處，以及如何消除由傳統的緩沖區處理方式引起的問題，所以他們提供了管理代碼的能力。必須注意管理代碼和非管理代碼間的交互問題。但是至少可以在您需要時適當保證應用程序的安全。
檢查錯誤
檢查所有調用函數的返回代碼。如果正在調用 Win32 API，請確保調用已成功完成。如果正在分配內存，請確保未返回 NULL 值。如果正在進行 COM 調用，特別是正在使用 Microsoft Visual Basic進行調用并且已指定“On Error Resume Next”語句，請確保未出現異常。同樣，不要對這類調用的結果做任何假設。
如果正在調用 Win32 安全函數，應特別小心。例如，如果正在調用 ImpersonateLoggedOnUser，應檢查返回代碼是否存在錯誤，否則將難以為用戶提供較高的安全環境。當您的 Web 應用程序配置為在 IIS 上以“進程內”方式運行時要格外注意這一點，因為代碼可能以本地系統帳戶運行，這在本地計算機上幾乎沒有限制。還應注意某些交叉的 COM 調用同樣可能在具有較高權限的線程中運行。
盡早、盡快地驗證輸入
XML Web 服務接收請求時，您應做的第一件事就是驗證提交的數據。根據架構進行 Web 服務說明語言 (WSDL) 驗證將會捕獲許多錯誤，但是您應立即執行所需的任何應用程序級的驗證。包括檢查特殊字符、檢查特定范圍內的數值、檢查字符串長度，等等。即使認為所有請求必須來自特定的應用程序，也應在進行證明之前假定傳入數據是無效的。事實是對 XML Web 服務的請求可以來自任何地方。如果對數據進行假設，應假定數據可能來自某個惡意用戶。
參數驗證代碼能夠快速地完成也是很重要的。識別無效請求的速度越快越好。否則 XML Web 服務容易遭受拒絕服務攻擊。如果您的服務器處理非法請求的時間較長，則很可能不能為合法請求提供服務。始終應用與專用數據同等的安全級別來對待消耗時間和資源的操作。如果必須執行耗時的 SQL 查詢，或者某個操作要求具有很強的處理能力，則首先要確保請求的合法性。用戶是否是合法用戶？對請求進行身份驗證不僅能防止無效用戶使用您服務器上的資源，并且提供了跟蹤審核日志中的錯誤使用情況的能力，使您可以發現特定用戶非法使用資源的情況。如果正在驗證輸入，應首先驗證用戶的憑據。如果使用普通 HTTP 身份驗證機制，則在代碼調用之前就會為您進行用戶身份驗證。
關閉后門
有時在項目的開發階段提供一種方法，以便在服務器上解決某些問題是非常合適的。例如，XML Web 服務經常會生成一個密鑰以便在多次調用之間標識同一個用戶，或在這些調用之間維護某種狀態。為方便調試經常會添加一段額外的代碼以接受由所有密鑰組成的密鑰，而不是生成真正的密鑰。但是，如果確實出于合法調試的目的提供了能避免某些檢測的機制，請確保在 XML Web 服務生效之前刪除這些后門。
同樣，請避免提供能忽略安全性問題的精巧機制，即使您認為從長遠來講它有助于支持服務的長期運行。請考慮 XML Web 服務正在進行應用程序級身份驗證的情況。以下做法可能是很吸引人的：即將秘密的管理員級用戶名硬編碼到您的代碼中，這樣就可以使那些忘記了自己的管理員帳戶密碼的人能夠進入系統。但是，第一個用戶使用了此后門后，機密就泄露了，此代碼的所有其他用戶將很容易受到攻擊。
事實上，甚至在第一次合法使用后門之前此機密就有可能泄露。如果后門帳戶和密碼在代碼中存儲為字符串，則其他人很容易通過交付的二進制文件看到已在代碼中定義的任何字符串。如果黑客在某個 DLL 中看到類似“SecretAdministrativeUser”的字符串，他就會懷疑此字符串可能是進入代碼的后門并嘗試使用它。
最后，關于后門，您不應提供通用方法來收集服務器上的信息。雖然它通常有助于為產品提供支持，但在很多情況下，它會產生相反的結果。不要創建可以查看或下載配置文件或系統中源代碼的代碼。盡管創建這類代碼便于分析服務器上的異常情況，但是黑客也會利用它得到同樣的信息。通常，用戶名和密碼存儲在配置文件中，而且很多公司認為其源代碼的知識產權是其最寶貴的資產。當您考慮到這種能力通常也能查看服務器上其他應用程序的文件時，上述風險會更大。所以，即使 XML Web 服務代碼在這些能力面前是無懈可擊的，服務器上仍可能存在較易受到攻擊的應用程序。
總結
對 Web 系統的攻擊確實發生過，例如紅色代碼蠕蟲病毒及其變體就是非常令人頭疼的例子。幸好，可以采取一些措施來減少 XML Web 服務的風險級別。希望我們能使您了解某些可能出現的弱點以及如何避免這些弱點，這樣，您就可以創建安全的 XML Web 服務了 。
