談談SOA面向服務體系架構的安全問題

申請免費試用、咨詢電話：400-8352-114

本文我們討論的是面向服務體系架構（SOA）的安全應用。在展開討論之前，首先讓我們來解析面向服務體系架構的實際含義。面向服務體系架構是一種涉及若干以服務為導向的應用軟件的體系架構。最初面向服務體系架構中的服務與一系列技術相關，包括SOAP, WSDL和UDDI。不過許多研發(fā)人員對REST（表象化狀態(tài)轉變，簡稱REST）服務顯示出更大的興趣，由此REST成為面向服務體系架構中廣為接受的組成部分。由于REST被廣泛應用于Web 2.0軟件，因此Web2.0的興起也鞏固了REST在面向服務體系架構領域中的地位。最近云服務（諸如亞馬遜在線的簡單查詢服務SQS）也開始和本地服務并駕齊驅，共同創(chuàng)建混合面向服務體系架構環(huán)境。所有這些使得面向服務體系架構成為包含最初的SOAP/REST/VDDI堆棧，REST服務和云的集合體。從安全應用的專業(yè)角度來看，所有這些都必須得到安全保障。

提及面向服務體系架構安全，首先要問的是為什么。為什么要對面向服務體系架構實施安全保障呢？毋庸置疑的答案就是要保護面向服務體系架構不受攻擊。這是一個合理的理由，但是應用面向服務體系架構安全還有其他不可忽視的動因，諸如監(jiān)控面向服務體系架構中服務的使用。我們首先從審查面向服務體系架構技術（包括SOAP和REST）的攻擊漏洞開始。然后我們將審核諸如WS-Security等安全標準如何應用到面向服務體系架構，如何通過協(xié)議實現(xiàn)控制使用和監(jiān)控，最后我們將檢查企業(yè)在整合本地網(wǎng)站應用軟件和云計算服務時可能產(chǎn)生的安全隱患。

面向服務體系架構風險綜述

在面向服務體系架構中影響XML和REST服務的內容風險是什么？在XML里，有幾種大家所熟知的攻擊風險，諸如XML Entity-Expansion和SQL注入式攻擊。

SQL注入式攻擊

在面向服務體系架構中，SQL注入式攻擊會將SQL碎片插入XML數(shù)據(jù)，然后將錯誤的數(shù)據(jù)返回，或者制造泄露數(shù)據(jù)庫訪問信息的錯誤。

在面向服務體系架構中能實施成功的SQL注入式攻擊需要兩個先決條件：

--面向服務體系架構中服務接受的數(shù)據(jù)被直接插入SQL Statement。

--SQL Statement在執(zhí)行攻擊時有足夠的優(yōu)先權

為了避免受到攻擊，必須確保從可疑用戶處接受的數(shù)據(jù)不會直接插入SQL Statement。對接受的文件內容執(zhí)行內容驗證和風險偵測以便進行防范。

捕捉-重放攻擊（Capture-replay attack）

想象一下：面向服務體系架構中的服務受到協(xié)議的保護，服務請求需要數(shù)字簽名。這看起來很安全，但結果真是這樣嗎？答案是這種系統(tǒng)存在重放攻擊的弱點，系統(tǒng)只需簡單的重新播放驗證的簽名信息就能實現(xiàn)未經(jīng)授權的訪問。

解決這種問題的答案涉及時間戳的使用。網(wǎng)絡服務安全性（WS-Security）標準就包括對時間戳的支持。網(wǎng)絡服務協(xié)議（WS-Policy）可以用來掌控信息中出現(xiàn)的簽名時間戳，因此重新播放的信息時間戳過期就會被系統(tǒng)偵測到。用戶必須認真制定時間戳信任間隔。這個間隔必須足夠短，只有這樣攻擊者才沒有時間對驗證信息進行捕捉，破解和重放。但是時間戳信任間隔又必須足夠長，以便在網(wǎng)絡服務系統(tǒng)時鐘和網(wǎng)絡服務請求之間細微的差別不會導致驗證信息被阻隔。

XML外部實體攻擊（External Entity Attack）

所謂的XML外部實體攻擊是通過DTD（文件類型定義）入口將外部數(shù)據(jù)嵌入到XML文檔中。通過指定一個本地文件會產(chǎn)生某些XML引擎，通過本地文件系統(tǒng)訪問未經(jīng)授權的信息。請注意SOAP不允許使用DTD。

XPath注入（XPath Injection）

XPath注入式攻擊與SQL注入類似，它被用于從XML數(shù)據(jù)庫中竊取信息。如果能確保進入XPath的數(shù)據(jù)本身不包含XPath，那么XPath注入攻擊就能被阻斷。

XML拒絕服務（XDOS）

這種攻擊包含了文件類型定義的特性，即攻擊可以進入DTD定義的實體。通過遞歸進入實體，攻擊者可以制造在內存中爆炸的XML信息（因此這個術語也被稱之為“XML炸彈”），從而導致拒絕服務。

有害的SOAP附件

像電子郵件信息一樣，SOAP信息也包含附件。如果這些附件很大而且很難打開，那么它可能含有病毒或者其它危險。解決這個問題的方案是確保SOAP附件可以基于MIME類型進行阻斷和過濾，或者通過病毒掃描進行偵測。

XML簽名差異攻擊（Signature dereference attack）

XML簽名包括指向簽名數(shù)據(jù)的參考要素。解析應用軟件必須對參考URI解除參照。XML簽名標準陳述如下：“XML簽名應用軟件必須能夠解析URI語法。我們推薦在HTTP中對URI進行參照解除”。不過如果參考數(shù)據(jù)是偽造的就會帶來風險。

REST Web 2.0和面向服務體系架構

盡管面向服務體系架構最初是和SOAP，WSDL和VDDI三者聯(lián)系在一起的，但許多研發(fā)人員寧愿使用REST服務，因為REST更加接近網(wǎng)站上的瀏覽器界面。Web 2.0的蓬勃發(fā)展對其起到了推波助瀾的作用，因為豐富互聯(lián)網(wǎng)應用軟件（RIS）就是利用REST服務將數(shù)據(jù)從網(wǎng)絡服務器傳遞到瀏覽器。能利用Web 2.0的技術包括瀏覽器端的JavaScript，多數(shù)稱之為REST網(wǎng)絡服務的部分都是在服務器端發(fā)生的。舉例來說，F(xiàn)lickr網(wǎng)站包括在瀏覽器中運行的JavaScript腳本，我們稱之為服務器端的網(wǎng)絡服務，可以對照片進行更名。為了撤銷XML或者JSON（JavaScript目標符號）數(shù)據(jù)，客戶端的“AJAX”（非同步JavaScript和XML）可以召回服務器上的網(wǎng)絡服務。這種行為不是同步發(fā)生的，用戶無需瀏覽新的網(wǎng)頁。

在Web 2.0的世界中，這成為攻擊關鍵點的后端網(wǎng)絡服務。有時這種網(wǎng)絡服務被定義為Web 2.0的“大型攻擊界面”。攻擊者會試圖通過它的客戶端界面攻擊應用軟件，或者他們會簡單的繞過后端網(wǎng)絡服務界面長驅直入。

問題依然存在

在這點上，很多讀者可能會認為“這和傳統(tǒng)的網(wǎng)絡應用軟件并沒有實質不同，因此為什么要對它單獨進行安全保障？”，畢竟在Web 2.0 環(huán)境中，用到的是網(wǎng)絡瀏覽器和網(wǎng)絡服務器，涉及的是一個用戶。確實當數(shù)據(jù)在網(wǎng)絡瀏覽器和網(wǎng)絡服務器之間傳輸時，對SQL注入或者交叉腳本的攻擊跡象進行數(shù)據(jù)掃描就可以了。當XML在網(wǎng)絡上，你就必須對XML拒絕服務或者XPath注入等攻擊也進行掃描。另外，保證譯碼安全也同樣重要。瀏覽器上的豐富應用軟件承擔著增強安全譯碼的職責。如果攻擊者將JavaScript腳本插入遞歸下行至瀏覽器的數(shù)據(jù)，那么交叉腳本也是可能的。因為許多Web 2.0的腳本交叉都取決于服務于客戶的JavaScript。帶病毒的JavaScript傳播的可能性就會變?yōu)楝F(xiàn)實。因此也必須進行偵測和隔離。

Freemium模式和數(shù)據(jù)被盜的風險

所謂的Freemium網(wǎng)絡服務指的是免費提供的基礎服務，如果有特殊需求或者增強型服務再另行收取額外費用。Freemium這個詞本身是兩種商業(yè)模式，免費和收費合二為一的混合詞。

允許某些在面向服務體系架構中的服務在Freemium模式下運行是很很吸引眼球的，因為它提供了一種付費商業(yè)模式的途徑。不過這種模式的實用性更加復雜。 Freemium模式要預先設定面向服務體系架構安全框架，這個框架能夠偵測服務的過度使用，強迫用戶對使用的服務進行付費。使用服務必須通過驗證以便系統(tǒng)能偵測到某個特別用戶過度使用了服務，從而要求用戶進行付費。通常Freemium模式是使用研發(fā)人員代號來實現(xiàn)的。這些代號是嵌入在網(wǎng)絡服務符號庫中的，能傳遞給所提供的服務。舉例來說，用戶可以使用搜索服務來尋找特定的點，但是他們無法在不被察覺的情況下進行數(shù)據(jù)搜索，系統(tǒng)會要求他們進行付費。

當用戶在面向服務體系架構中實行Freemium服務模式時，企業(yè)可以選擇編譯自定義代碼來執(zhí)行，或者使用非定制的產(chǎn)品來實現(xiàn)，諸如XML網(wǎng)關。XML網(wǎng)關的優(yōu)勢是在無需改變實際代碼的前提下就能更改模式中的參數(shù)。XML網(wǎng)關也能對我們前文所討論的攻擊進行掃描，諸如病毒代碼注入。

身份驗證和標準

了解是誰在使用面向服務體系架構中的服務是很重要的，使用這些信息進行訪問控制和通過審計跟蹤維護信息安全也是如此。對服務的訪問控制服務也要利用各種不同的標準，某些標準是X.509證書類型的，某些是SAML和網(wǎng)絡服務安全這樣的新標準。重要的是我們不要被這些標準所蒙蔽，特別是當他們以一種復雜的方式組合在一起時。

新與舊：密碼，X.509證書和網(wǎng)絡服務安全（WS-Security）

密碼的使用已經(jīng)由來已久。目前在面向服務體系架構安全中依然應用廣泛。在很多情況下只是HTTP驗證這種簡單的問題，可以通過SSL傳遞出去以便密碼不會被泄露。事實上即使是使用了數(shù)字簽名驗證，密碼的泄露也很難完全避免，因此為了阻隔特定的捕捉-重放攻擊，SSL還應該別使用。盡管通過SSL進行HTTP驗證是一項古老的技術，但它在面向服務體系架構的點對點身份驗證中依然應用廣泛。

X.509證書被應用于SSL驗證中，網(wǎng)絡服務可以向客戶證明它的身份，或者在雙向SSL中，客戶還能向服務證明自己的身份。在這種情況下身份驗證是沒有定形的，因為網(wǎng)絡服務交叉性經(jīng)常會涉及應用程序與應用程序的對話。由此這里的驗證也是對應用程序的驗證。這些情況都是使用X.509證書，信任也是基于X.509證書的發(fā)行者（即授權機構，簡稱CA）。

和SSL一樣，X.509證書經(jīng)常會用于數(shù)字簽名。XML簽名是定義XML數(shù)據(jù)如何使用與X.509證書吻合的私人密鑰來進行數(shù)字簽名的標準，這樣任何持有X.509證書簽名方的用戶都可以對簽名進行驗證。

XML 加密也是一項定義XML數(shù)據(jù)如何加密的標準。或許你會問“在加密XML數(shù)據(jù)和加密其他類型數(shù)據(jù)之間有什么不同？”，答案是XML數(shù)據(jù)可以有選擇性的進行加密，比如說有選擇性的對醫(yī)療記錄中患者姓名進行加密。由于面向服務體系架構中的信息多數(shù)都是XML的（REST和用于Web 2.0的JSON除外），XML加密在隱私保護方面非常有用。

Kerberos也是一項成熟的技術，能繼續(xù)應用在面向服務體系架構安全中。特別是Kerberos經(jīng)常會用于Windows環(huán)境中，因為它也加強了Windows網(wǎng)絡中的身份驗證和單一簽名安全。

所有這些已經(jīng)存在的安全技術都會繼續(xù)應用在面向服務體系架構安全之中。

網(wǎng)絡服務安全（WS-Security）

網(wǎng)絡服務安全是在2004年才實施標準化的一項新興技術，它是在先前技術的基礎上建立起來的。它是定義XML加密和XML簽名如何應用到SOAP的標準，這樣SOAP信息就可以被加密或者簽名。另外，它還定義了密碼和X.509證書在SOAP信息中的位置，SOAP如何與Kerberos共同運作。使用網(wǎng)絡服務安全標準可是實現(xiàn)不同應用程序之間的協(xié)同工作。

諸如Suns Glassfish和微軟.NET這樣的平臺都能與網(wǎng)絡服務安全標準相結合。這些技術能處理簽名XML（使用網(wǎng)絡服務安全標準的XML簽名），身份驗證（使用密碼，Kerberos或證書）和加密（使用網(wǎng)絡服務安全標準的XML加密）。

XML網(wǎng)關

XML 網(wǎng)關能通過提供網(wǎng)絡上的安全處理和硬件加速來保障面向服務體系架構的安全。XML網(wǎng)關將安全協(xié)議應用到需要保護的面向服務體系架構服務。它代表的是位于真實網(wǎng)絡服務前端的虛擬服務。這些虛擬服務可以被提速，還可以包括在真實面向服務體系架構服務之前發(fā)生的過渡服務。舉例來說，XML網(wǎng)關可以呈現(xiàn)在真實 SOAP網(wǎng)絡服務前端的REST界面。用這種方法，XML網(wǎng)關通常能提供協(xié)議調解，信息過渡，硬件加速以及安全。

面向服務體系架構安全到云的未來

根據(jù)內部應用軟件到網(wǎng)絡應用軟件的概念進行定義，面向服務體系架構目前正在尋找與云計算的連接。由亞馬遜在線，F(xiàn)orce.com和谷歌等提供的服務都是這種全球性面向服務體系架構。他們能提供多種網(wǎng)絡服務，通常都可以通過與應用軟件結合的REST和AJAX界面來實現(xiàn)訪問。

目前占據(jù)主導地位的方式是混合模式，即在本地面向服務體系架構上的服務和云上的服務混合使用。舉例來說，本地應用軟件可能已經(jīng)將銷售數(shù)據(jù)從數(shù)據(jù)庫中導出，然后將其放在 TIBCO Rendezvous查詢中。Force.com中召回的數(shù)據(jù)在放入Rendezvous查詢之前可能會被用于豐富數(shù)據(jù)。另一個例子是本地應用軟件使用亞馬遜S3服務來進行存儲。

在連接到云上的本地面向服務體系架構的混合模式中，很重要的一點是確保沒有私人數(shù)據(jù)被傳輸?shù)皆粕?。也可以通過對傳輸?shù)皆粕系臄?shù)據(jù)進行選擇性加密來實現(xiàn)安全保障。另外，網(wǎng)絡中斷或者云服務故障不會經(jīng)常影響到本地應用軟件也很重要。用戶可以使用XML網(wǎng)關作為本地“Cloud Broker”來控制從本地面向服務體系架構到云上的連接。（安全在線）