保護 XML Web 服務免受駭客攻擊(4/end)

來源:互聯網
上載者:User
web|xml|攻擊

定義介面


與其他 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++ 程式員,應對以下函數格外小心: strcpystrcatmemcpygetssprintfscanf 以及所有這些函數的變體(如 lstrcpywcscpyCopyMemory 等等)。請注意 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 服務了。


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。