利用soap消息與web服務(wù)通信_第1頁
利用soap消息與web服務(wù)通信_第2頁
利用soap消息與web服務(wù)通信_第3頁
利用soap消息與web服務(wù)通信_第4頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權(quán)，請進行舉報或認(rèn)領(lǐng)

文檔簡介

利用soap消息與web服務(wù)通信

1soap協(xié)議的安全性分析web服務(wù)是下一個分布系統(tǒng)的核心組成部分。服務(wù)用戶與web服務(wù)之間的通信基于soap。SOAP是在分散或分布式的環(huán)境中交換信息的簡單協(xié)議,并且是一個基于XML的協(xié)議,其特點在于其簡單性,這也是其設(shè)計目標(biāo)之一。正因為這一特性,在制定SOAP標(biāo)準(zhǔn)時并沒有過多考慮其安全性要求,但作為一個分布式環(huán)境中的信息交換協(xié)議,安全性是必不可少的。本文在充分研究SOAP消息協(xié)議及相關(guān)安全標(biāo)準(zhǔn)規(guī)范的基礎(chǔ)上,針對當(dāng)前Web服務(wù)的需求,提出了一種SOAP消息安全性的解決方案。2soap消息的上傳安全分析眾所周知,數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中可能會被他人竊取或篡改,從而造成泄密或重大經(jīng)濟損失。SOAP消息在傳輸時同樣存在這樣的安全隱患。為保護SOAP消息安全,必須對其進行安全處理,具體講就是要求SOAP消息滿足如下幾個要求:(1)完整性:保證沒有經(jīng)過授權(quán)的用戶不能改變或刪除信息,從而信息在傳送的過程中不會被偶然或故意破壞,保持信息的完整和統(tǒng)一。(2)機密性:保證沒有經(jīng)過授權(quán)的用戶、實體或進程無法竊取信息。(3)原始性證明:對信息或數(shù)據(jù)的發(fā)送者進行標(biāo)示。保證信息被經(jīng)過標(biāo)示的發(fā)送者所傳送,從而避免以前的數(shù)據(jù)包被重復(fù)發(fā)送。(4)防止抵賴:保證信息的發(fā)送者不能抵賴或否認(rèn)對信息的發(fā)送,當(dāng)然信息發(fā)送前需要對發(fā)送者進行安全認(rèn)證。下面將結(jié)合實例來說明在SOAP消息的傳送過程中如何滿足上述安全性要求。首先我們給出一個SOAP消息(見清單1),該消息向Web服務(wù)發(fā)送一個定單消息來完成網(wǎng)上訂購活動。消息包含兩個子元素<Header>和<Body>,<Body>元素是消息的主體。2.1消息摘要的處理SOAP消息在傳輸過程中,任何未經(jīng)授權(quán)的修改和刪除都是不允許的。為滿足該需求,通常的做法是對SOAP消息進行數(shù)字簽名。要對清單1所示的SOAP消息進行數(shù)字簽名,首先要確定消息的簽名體。在清單2中,<Transforms>元素通過XPath描述的路徑來指定被簽名元素在消息文檔中的位置,在本例中它表示簽名的部分是消息的路由報頭和消息主體。由于不同的應(yīng)用對XML文檔的編碼及屬性排序等方面的處理可能不同,因此邏輯上相同的文檔在簽名后可能會得到不同的結(jié)果,從而造成簽名有效性驗證上的錯誤。為避免這種錯誤的發(fā)生,消息的簽名部分要通過<CanonicalizationMethod>元素所指定的算法進行規(guī)范化處理,得到統(tǒng)一規(guī)范化的XML文檔。在此基礎(chǔ)上,通過<DigestMethod>元素指定的HASH算法對該規(guī)范化的文檔進行散列處理以獲得消息摘要。該摘要將附加在消息中發(fā)送到接收方,接受方可以從<DigesValue>元素中獲得該摘要值。簽名即是對消息摘要用簽名算法和簽名密鑰進行加密的過程。在清單2中,簽名算法由<SignatureMethod>元素指定,密鑰的相關(guān)信息則包含在<KeyInfo>元素中。<KeyInfo>元素的子元素<wsse:SecurityTokenReference>通過一個URI指定了簽名密鑰位置。在清單2中,id為“TOKEN”的<wsse:BinarySecurityToken>元素就是簽名密鑰。例中用于簽名的密鑰是消息發(fā)送方的私有密鑰,其目的是為了保證不可抵賴性,詳細(xì)原因?qū)⒃谙挛恼f明。上述簽名信息全部封裝在一個<wsse:Security>元素中,并作為SOAP消息<Header>元素的子元素發(fā)送到消息接收方,接收方收到消息后,根據(jù)獲得的密鑰解密簽名值獲得消息摘要,并與重新計算的摘要值進行比較,以驗證消息的完整性。2.2加密對稱密鑰由于TCP/IP協(xié)議的不安全性,消息在網(wǎng)絡(luò)中是以明文的形式傳輸,網(wǎng)絡(luò)中的監(jiān)聽者可以輕易地獲得消息發(fā)送者可能需要保密的信息。尤其是在電子商務(wù)中,可能要將一些機密的信息如銀行帳號等在網(wǎng)上發(fā)送,如果這些信息被懷有惡意的人獲取,則可能造成嚴(yán)重的后果。因此,我們需要對消息進行加密處理,使得只有合法的消息接收者才可以獲得消息的內(nèi)容,以保證消息的機密性。加密算法分為對稱加密算法和不對稱加密算法。對稱加密算法的特點是密鑰由消息發(fā)送方和接收方共享。由于消息的加密解密都要依賴于該共享密鑰,因此,保護該密鑰的安全是保證消息機密性的關(guān)鍵。由于該密鑰通常由一方生成并傳給另一方,在此傳送過程中,密鑰將受到安全性威脅,不利于保證消息的機密性。而對于不對稱加密算法來說,存在一個公有/私有密鑰對,被密鑰對中某個密鑰加密的信息只能用與之對應(yīng)的另一個密鑰解密。這樣,消息的發(fā)送方/接收方可以將各自的公有密鑰發(fā)送給對方,在發(fā)送消息時,利用對方的公有密鑰對消息加密。這樣,就只有擁有相應(yīng)私有密鑰的一方才可以解密該消息,保證了消息的機密性。但是,不對稱加密算法的計算速度較慢,從而影響其效率。因此,為在保證效率的前提下完成對消息的加密,通常將兩種算法結(jié)合起來來完成加密處理,即用對稱加密算法對消息加密,而用不對稱加密算法加密對稱密鑰。這樣,就只有擁有私有密鑰的接受方才能解密該消息,從而解決消息機密性問題。在清單1中消息的<body>部分包含了機密信息,需要加密處理,加密后的結(jié)果如清單3所示。被加密部分由<enc:EncryptedData>和<enc:EncryptedKey>兩個元素取代,<enc:EncryptedData>元素包含了有關(guān)消息加密的信息,其中加密算法、密鑰以及加密結(jié)果分別對應(yīng)于其子元素<enc:EncryptionMethod>、<ds:KeyInfo>和<enc:CipherData>。加密密鑰是對稱密鑰,為了保護其安全需對它進行加密,加密后的密鑰被包含在<enc:EncryptedKey>元素中。在這里,我們使用消息接收方的公有密鑰來加密對稱密鑰。這樣,就只有擁有相應(yīng)私有密鑰的接收方才能夠獲得對消息加密的對稱密鑰,并用其解密消息的加密部分。2.3消息唯一性的驗證接收方收到一個消息時,需要確認(rèn)消息發(fā)送方的身份。為此,發(fā)送方需要在消息中提供一些能證明其身份的信息,這就是消息的原始性證明。在實際的解決方案中,可以利用數(shù)字簽名來提供消息的原始性證明。在對消息簽名時,使用發(fā)送方的私有密鑰進行簽名。這樣,擁有相應(yīng)公鑰的接收方在驗證簽名有效的情況下就可以確定消息發(fā)送者的身份。在清單2中,<wsse:BinarySecurityToken>元素包含一個X.509證書,證書內(nèi)容是對發(fā)送方的公有密鑰和身份信息的數(shù)字簽名,接收方信任該證書即表示其確認(rèn)了發(fā)送方的身份。原始性證明只能證明消息創(chuàng)建者的身份而不能證明消息發(fā)送者的身份,因為消息在不安全的網(wǎng)絡(luò)中傳輸,有可能會被網(wǎng)絡(luò)中的監(jiān)聽者所截獲。一些惡意的攻擊者可以將截獲的消息重復(fù)發(fā)送來對網(wǎng)絡(luò)服務(wù)進行攻擊,即再現(xiàn)攻擊。為了免受這類攻擊,我們必須結(jié)合一定的方法來保證信息的唯一性,如時間戳或nonces等。簽名日期和時間都附加在消息上,并與消息一起簽名。添加這些信息可以在其中加入擴展元素實現(xiàn)。這樣,消息的接收方在收到消息時可以對消息的唯一性標(biāo)示進行驗證。如果發(fā)生沖突或者不一致,接受方可拒絕發(fā)送方請求。2.4基于唯一標(biāo)注的消息簽名消息的發(fā)送方和接收方在消息的交換過程中,發(fā)送方和接受方必須對于自己的行為不可否認(rèn),以保證不可抵賴性。這是未來電子商務(wù)等網(wǎng)上交易活動所必須解決的問題。為使消息發(fā)送方不可抵賴其對消息的發(fā)送,可以利用發(fā)送方的私有密鑰對消息的散列值進行簽名。這樣,消息的接收方在接收到消息后可以通過相應(yīng)公鑰重新計算消息的摘要值,并同發(fā)送方的摘要值相比較。如果一致,則消息一定是發(fā)送方發(fā)送的,發(fā)送方不可抵賴。但是,請注意,我們可以這樣做的前提是消息的發(fā)送者和消息的簽名者是相同的,因為消息可能是惡意的第三方的再現(xiàn)攻擊。這樣,消息的創(chuàng)建者可以抵賴其對消息的發(fā)送。因此,為了滿足不可抵賴性要求,需要在向消息中添加唯一標(biāo)示的基礎(chǔ)上對消息進行數(shù)字簽名。在清單1中,為保證SOAP消息的不可抵賴性,在消息的主體部分包含了一個時間標(biāo)示。接收方在接收消息后要確認(rèn)消息時間標(biāo)示的唯一性,如果不唯一則可認(rèn)為該消息是無效的。在對包含該標(biāo)示的消息進行數(shù)字簽名時,我們使用發(fā)送方的私有密鑰。這樣,接收方就能夠確認(rèn)消息發(fā)送者的身份,防止發(fā)送方抵賴。3接收過程中被接收的安全綜上所述,為了滿足上述四個安全性要求,保護SOAP消息從創(chuàng)建發(fā)送一直到被接收整個過程中的安全,我們給出了如圖1所示的整體解決方案。該方案綜合以上分

溫馨提示

  • 1. 本站所有資源如無特殊說明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽，若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間，僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理，對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容，請與我們聯(lián)系，我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論