|
在上一篇文章中，我們討論了不同種類的攻擊，以及如何進行配置以免受到攻擊。本文中，我們將集中討論如何進行設計和開發，以免受到攻擊。
首先，我想介紹兩個非常好的新工具，它們是 Microsoft® 開發的，可使您的 Web 服務器獲得最大的安全性。IIS Lockdown Tool（英文）可以最大限度地防止可能的攻擊者對您的 Microsoft® Internet Information Server (IIS) 進行訪問。鎖定工具還提供了“advanced”選項，您可以在其中選擇所需設置。此外還提供了“rollback changes”選項。當您對所做更改不滿意時可選擇該選項。請嘗試該工具。
另一個重要工具是用于 IIS 5.0 的 Hotfix Checking Tool（英文）。該工具會查詢由 Microsoft 發布的所有可用安全性修補程序的 XML 文檔（該文檔是不斷更新的），然后將此文檔與本機安裝的文檔進行比較并報告其差異。使用該工具可以更輕松地管理單個 Web 服務器或大型 Web 領域的安全修補程序。
設計問題
設計 Web 服務時必須認真考慮安全問題，以及如何能夠使遭受攻擊的危險性降到最低。許多在試圖防止攻擊時可能起作用的因素都可以在設計時予以考慮。例如考慮如何進行身份驗證，或希望返回哪類錯誤等問題。
確定安全需求
在 XML Web 服務設計的早期，您需要確定所需的安全級別。某些 XML Web 服務根本不需要身份驗證，而其他服務對于確定使用該服務的用戶有非常嚴格的要求。由 XML Web 服務接收和發送的數據需要何種隱私級別？如果某個 XML Web 服務用戶聲明他們未請求您記錄中所指明的服務，則在工時、處理能力或法律費用方面可能要花費哪些成本？
首先，讓我們來看一下身份驗證。某些種類的身份驗證會比其他身份驗證更容易遭受攻擊。在低端，如果您使用“HTTP 基本身份驗證”，則可以看到網絡上的數據包的所有用戶都能看到您的用戶名和密碼。如果通過 Internet 發送請求，則您無法控制能看到您的數據包的用戶。在身份驗證級別的高端，您可以考慮使用 SSL 客戶端證書進行身份驗證，該證書提供了一個編碼的通道，并使數據包的惡意攻擊者很難進行攻擊。有關身份驗證選項的詳細討論，請參閱 At Your Service 專欄中 Mary Kirtland 的 Authentication and Authorization（英文）。
我們已經間接提到了身份驗證過程中的隱私問題，當涉及到電子欺騙時您應考慮此問題。您還需要知道與所有從 XML Web 服務發送和接收的數據有關的隱私問題，而不僅僅是用戶名和密碼。例如，您可能會為通過身份驗證的用戶生成一個會話密鑰，該用戶將此密鑰隨每個請求一起發送以標識自身。如果此密鑰未加密發送，則數據包的惡意攻擊者可以看到此密鑰，并用它向您的 Web 服務發送自己的請求，這樣您的 Web 服務會將其看作是原來那個合法用戶。
另一個隱私問題是由 Web 服務發送和接收的簡單數據。該數據是否因其敏感性強而需要加密？SSL 加密的代價是 Web 服務會發送和接收整個加密的通道，從而降低性能。您或許可以只加密請求中的敏感項，但您隨后可能需要在客戶端上安裝自定義編寫的軟件以啟用加密/解密。使用 SSL 加密整個通道的一個優點是：目前大多數客戶端平臺都支持基本 SSL 通信，而不需要針對應用程序編寫特定代碼。
就基本安全性設計而言，還必須考慮否認的概念，即一個用戶可以拒絕承認其通過 XML Web 服務執行的操作。例如，如果您提供股票交易服務，而某些人聲稱他們沒有要求您的系統為其出售股票，并且要否認此出售命令。很明顯，與其他服務相比，某些 XML Web 服務對這種問題可能會更為關心，但是您應該確定您的服務可能會遇到的危險，以及在方案中應采取什么樣的有效措施。
使用安全的身份驗證系統肯定是避免出現這類危險的首要步驟。例如，使用 HTTP 基本身份驗證可能是不安全的，但是通過使用 SSL 的加密通道來使用此身份驗證則是安全的。如果用戶使用空密碼或容易猜到的密碼，即使具有安全的身份驗證系統也是沒有用的。強制使用強加密密碼是防止出現此類問題的重要步驟。總之，用戶和服務執行者都有責任防止密碼泄露。
最后，如果不審核通過服務發生的事件，當出現否認情況時，安全的身份驗證和強加密密碼都是毫無意義的。當事務中存在否認威脅時，應記錄這些事務及其用戶、時間、日期等足夠多的信息以標識事務的詳細信息。否則，當出現爭論時，您可能缺少足夠的證據以證實您的觀點。
審核、報告和監視
審核對減少否認危險程度起著重要的作用；在識別其他種類的攻擊過程中，也起著關鍵作用。例如，如果不是您的審核記錄中的統計數據表明您的服務存在異常使用情況，您可能根本意識不到您的服務正在遭受攻擊。例如，您是否注意到某個人正在對登錄方式進行字典攻擊？所以，我們將講述在審核、報告和監視時需要考慮的問題，以保護 XML Web 服務免受攻擊。
審核的概念就是記錄所發生的每個事件的所有信息。但是，當通過 XML Web 服務的數據量很大時，此想法可能是不切實際的。審核記錄至少應包括所有請求的時間、日期和 IP 地址。如果 XML Web 服務經過身份驗證，您需要在每個審核記錄中包括用戶名。如果您的服務支持多種方法或消息格式，您需要標識調用的是哪一個。最后，您需要包括足夠的信息以滿足您標識調用詳細信息的需要。例如，如果 XML Web 服務使用了一種方法，您可能希望記錄傳遞給該方法的所有參數。
您還需要考慮其他需要，例如當站點遭到攻擊時您可能需要回滾事務。而且，您的審核記錄往往是某些報告的最佳信息源。由于審核記錄可能相當大，您需要協調審核設計和備份策略。
審核處理的是通過您的服務同時發生的所有事件的記錄，報告則是向用戶、操作員和管理員匯報系統的使用信息。報告是保護 XML Web 服務免受攻擊的一個重要部分，因為通過它可以觀察服務的使用情況。一種主要的報告類型是報告發生的錯誤。報告 XML Web 服務所遇到的錯誤的能力是最重要的。同樣，您還需要報告那些可能指出惡意客戶端企圖的錯誤。例如，如果所接收請求中的某個參數是一個異常的長字符串，則您需要以一種容易引人注意的方式來報告該錯誤。對于這種類型的錯誤，您應該在應用程序事件日志中創建事件，這樣可以相應地對它們進行監視。有關如何將事件寫入事件日志的詳細信息，請參閱操作系統平臺 SDK 中的 Event Logging（英文）。
另一種對您的服務至關重要的報告類型是匯總服務使用情況的報告。它應該有兩種形式：首先，創建供您個人進行分析的全局報告，您可以使用該報告檢測使用級別或異常模式。應該對正常報告的外觀具有足夠的了解，這樣您才能夠發現異常使用的情況。其次，需要為您的用戶提供報告。您的用戶還應能夠監視他們對服務的使用情況。很有可能出現這樣的情況：在全局報告中未記錄攻擊行為，而個別用戶卻能立即在其各自的報告中發現問題。
如果 XML Web 服務正在 Internet Information Server (IIS) 上運行，那么我們就有必要提及一種能免費得到的非常有用的報告類型。即，為所有傳入的 HTTP 請求（包括對您服務的請求）進行的 IIS 日志記錄。您可以使用 IIS 日志中提供的信息來改進自己的報告。 '
最后，實施了審核及適當的報告方法后，您需要使用某種機制以發現所報告的問題。這就是監視。
可以以不同級別進行監視。當然，定期手動查看報告是監視 XML Web 服務的使用情況的一種方式，但是還應檢查事件日志中已報告的錯誤，使用性能監視日志，并利用可以監視 Web 服務器停機時間的多種工具中的一種。性能監視對于檢測攻擊可能是非常關鍵的。幸好，與 IIS 關聯的大量性能計數器可以為檢測問題提供許多重要的統計數據。
您可能還希望為 XML Web 服務創建自己的性能計數器。有關創建您自己的性能計數器的詳細信息，請參閱 Performance Monitoring（英文）。為了確保引起您對異常情況的特殊關注，應以某種形式通知您正在發生的事件，這點是非常重要的。可以在異常事件發生時，利用性能監視警報發送彈出式消息，或運行某個程序。圖 1 顯示的性能監視警報會監視未完成的 IIS ISAPI 請求的數量，以及當前隊列中的 ASP 請求的數量。
<IMG SRC=http://cfan.net.cn/info/"http://www.microsoft.com/china/msdn/images/service09192001.gif" border=0>
圖 1：創建性能監視警報
如果不對可能發生的問題采取一些措施，則對濫用的操作進行審核、報告和監視不會有任何用處。拒絕服務攻擊可能會被定義到特定的 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 錯誤,而不是一般的工具包錯誤。一般的工具包錯誤可以提供大量的、有關錯誤出現時在服務器上所發生情況的信息。在開發階段，工具包錯誤對于調試來說是很有用的，但是它們在產品服務器上不應出現。他們可以為黑客提供大量的、具有潛在破壞性的信息。
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 身份驗證機制，則在代碼調用之前就會為您進行用戶身份驗證。
|
