劉寶龍，楊 威，陳 樺

(西安工業(yè)大學(xué) 計算機(jī)科學(xué)與工程學(xué)院，陜西 西安 710021)

XML重寫攻擊檢測技術(shù)研究

劉寶龍，楊 威，陳 樺

(西安工業(yè)大學(xué) 計算機(jī)科學(xué)與工程學(xué)院，陜西 西安 710021)

細(xì)粒度的XML數(shù)字簽名中存在重寫攻擊的問題，已有多種方案用來檢測XML重寫攻擊。文中在分析評估了這些檢測方案的基礎(chǔ)上，討論了針對各種常見重寫攻擊類型的安全應(yīng)對方案以及各種檢測方案的最佳應(yīng)用場景。研究結(jié)果表明：安全策略、驗證互補(bǔ)(過濾器)、FastXPath以及標(biāo)記DOM樹中元素位置方案能有效地檢測到常見的重寫攻擊方式，且除內(nèi)聯(lián)法及驗證互補(bǔ)(位置指示器)方案外，已有方案都可應(yīng)用于有效的檢測中間人攻擊和重放攻擊的場景中。然而，針對修改簽名元素上下文關(guān)聯(lián)信息的攻擊方式，已有方案都不能檢測到。

XML重寫攻擊；安全策略；SOAP Account；驗證互補(bǔ)；FastXPath；重定向攻擊；多Security頭攻擊

0 引 言

隨著Web服務(wù)的迅速發(fā)展和廣泛應(yīng)用，其通信安全問題日益重要。Web服務(wù)間的通信是使用基于XML格式的SOAP消息實現(xiàn)的。XML數(shù)字簽名可以對SOAP消息的特定部分簽名，實現(xiàn)細(xì)粒度的簽名，這也導(dǎo)致了XML重寫攻擊問題的出現(xiàn)，進(jìn)而威脅到SOAP消息的傳輸安全。2005年，McIntosh和Austel首次提出了XML重寫攻擊[1]。XML重寫攻擊是指Web服務(wù)中對SOAP消息的惡意攔截、操作和傳輸?shù)目偡Q。目前，已有多種檢測XML重寫攻擊的方案，它們分別能檢測到某些攻擊類型，但是各自并不能檢測到所有的攻擊類型。文中在分析評估了這些檢測方案的基礎(chǔ)上，討論了針對各種常見攻擊的安全應(yīng)對方案以及每種方案的最佳應(yīng)用場景，為Web服務(wù)中針對XML數(shù)字簽名的應(yīng)用提供了參考。

1 已有的XML重寫攻擊檢測方案

1.1 安全策略

Web服務(wù)安全策略用來描述Web服務(wù)的安全能力或者安全需求。WS-Policy[2]為描述Web服務(wù)的安全策略提供了一個通用的策略框架。WS-SecurityPolicy[3]定義了用于描述各種安全需求使用的安全策略斷言集。Web服務(wù)安全策略中通過安全策略斷言來指定SOAP消息的簽名部分以及簽名消息使用的安全令牌，以此來保護(hù)SOAP消息的完整性。

在執(zhí)行安全通信前，服務(wù)方基于WS-Security規(guī)范的安全機(jī)制定制自己的安全需求，在WS-Policy策略框架下，使用WS-SecurityPolicy定義的斷言集描述安全需求并生成安全策略文件，再通過WS-PolicyAttachment機(jī)制實現(xiàn)安全策略文件與Web服務(wù)的綁定。請求方獲取服務(wù)方的安全策略文件，根據(jù)其中的安全需求對SOAP消息進(jìn)行安全處理，并將處理后的消息發(fā)送給服務(wù)方。服務(wù)方根據(jù)安全策略文件對其進(jìn)行安全驗證，根據(jù)驗證結(jié)果來決定是否建立整個通信過程。

由于策略文件的復(fù)雜性，Web服務(wù)所需的安全策略可能并不完善。微軟的SAMOA項目研究人員提出基于TulaFale形式化驗證[4]以及WSE policy advisor[5]工具來檢驗安全策略文件中是否存在XML重寫攻擊漏洞，使策略文件的作者可以根據(jù)漏洞修正安全策略，以提高策略文件的安全可靠性。

1.2 內(nèi)聯(lián)法

(1)SOAP Account方法。

SOAP Account方法[6-9]通過添加一個新的SOAP Account元素來標(biāo)記SOAP消息的結(jié)構(gòu)信息，這個元素在消息創(chuàng)建時被添加進(jìn)來。

SOAP Account元素中包含的SOAP結(jié)構(gòu)信息如下：

·Envelope元素的子元素個數(shù)；

·SOAP Header子元素的個數(shù)；

·簽名中引用的個數(shù)；

·每個簽名對象的后繼和前驅(qū)關(guān)系。

(2)改進(jìn)的SOAP Account方法。

Benameur等對SOAP Account方法進(jìn)行了改進(jìn)[10]，修改了SOAP Account元素中標(biāo)記的結(jié)構(gòu)信息。

改進(jìn)的SOAP Account方法中，SOAP Account元素包含的SOAP信息如下：

·標(biāo)記簽名元素的層次信息；

·標(biāo)記簽名元素的父節(jié)點名稱；

·為簽名元素的父節(jié)點添加一個“ID”屬性，使它唯一地標(biāo)記簽名元素的父節(jié)點信息。

內(nèi)聯(lián)法中，SOAP Account元素在SOAP消息發(fā)送之前添加到消息的Header元素中。發(fā)送方必須對SOAP Account元素進(jìn)行簽名。在SOAP消息傳輸時，可能經(jīng)過一個或者多個中介體，中介體可以對SOAP消息進(jìn)行處理并添加自己的SOAP Account，但是每一個后繼中介體必須簽名自己的SOAP Account、前一個簽名節(jié)點的簽名信息以及自身需要簽名的內(nèi)容。接收方對簽名消息進(jìn)行驗證，并計算SOAP消息的SOAP Account信息，將計算結(jié)果和接收的SOAP Account元素標(biāo)記的信息進(jìn)行比較，如果不匹配，則SOAP消息可能受到了XML重寫攻擊。

1.3 驗證互補(bǔ)方案

該方案中提出修改簽名驗證函數(shù)，在簽名驗證有效的情況下，返回一個過濾器或者位置指示器[11]。這樣，可以通過以下兩種方式檢測XML重寫攻擊。

(1)簽名驗證函數(shù)返回一個過濾器。XML數(shù)字簽名實際上是對簽名對象的摘要值進(jìn)行簽名。過濾器的功能是只將Reference引用中進(jìn)行摘要值計算的數(shù)據(jù)傳送給應(yīng)用邏輯。這樣，只有簽名消息被傳送給應(yīng)用邏輯，應(yīng)用邏輯也就無法訪問那些可能包括攻擊信息的未簽名消息。因此，應(yīng)用邏輯處理的一定是簽名消息。

(2)簽名驗證函數(shù)返回一個位置指示器。通過位置指示器，應(yīng)用邏輯可以獲取SOAP消息中使用絕對XPath表達(dá)式表示的簽名節(jié)點的絕對路徑信息，并將它和消息發(fā)送前的絕對路徑信息進(jìn)行比較，如果不一致，則消息可能受到了攻擊。

1.4 FastXPath方案

該方案中使用FastXPath表達(dá)式對簽名對象進(jìn)行引用，以標(biāo)記文檔根節(jié)點到簽名節(jié)點的絕對路徑信息，通過固定簽名節(jié)點的位置，來實現(xiàn)檢測XML重寫攻擊的目的[12]。

FastXPath表達(dá)式是指不包含通配符的絕對XPath表達(dá)式。它不僅標(biāo)記了從文檔根節(jié)點到簽名節(jié)點路徑上的每一個節(jié)點名稱，還標(biāo)記了簽名節(jié)點的層次信息、父節(jié)點信息及在兄弟節(jié)點中的位置信息，嚴(yán)格限制了攻擊者修改文檔中簽名節(jié)點位置的靈活性。這樣，基于修改簽名位置信息重寫攻擊便可被檢測出來。

1.5 標(biāo)記DOM(Document Object Model)樹中元素位置

該方法是在SOAP消息頭中添加一個新的頭元素，來標(biāo)記SOAP消息的DOM樹中Envelope、Body和簽名元素的位置信息[13]。

在SOAP消息發(fā)送之前，發(fā)送方根據(jù)后序遍歷算法對SOAP消息的DOM樹進(jìn)行編碼，獲得SOAP元素在樹中的位置標(biāo)記，并在SOAP消息頭中創(chuàng)建頭元素，其中包括Envelope、Body和簽名元素的位置標(biāo)記。頭元素自身必須被簽名。接收方通過驗證SOAP消息生成的DOM樹中Envelope、Body以及簽名元素的位置標(biāo)記和元素中Envelope、Body以及簽名元素的位置標(biāo)記是否一致來檢驗SOAP消息是否受到了XML重寫攻擊。

2 針對常見攻擊的安全應(yīng)對方案

XML重寫攻擊中常見的攻擊方式有：封裝簽名消息添加到SOAP頭中的攻擊、重定向攻擊、多Security頭攻擊、修改上下文關(guān)聯(lián)信息的攻擊。本節(jié)在分析評估了已有檢測方案的基礎(chǔ)上，討論了針對各種常見攻擊的安全應(yīng)對方案，為有效檢測XML重寫攻擊提供理論參考。

2.1 封裝簽名消息添加到SOAP頭中的攻擊

封裝簽名消息添加到SOAP頭中的攻擊是指攻擊者將簽名消息封裝到偽造的頭元素里并添加到SOAP消息頭中，使其不被接收端的應(yīng)用邏輯處理，并在原簽名消息的位置添加自己的攻擊信息，使應(yīng)用邏輯處理添加的攻擊信息。

安全策略方案中可指定使用絕對XPath表達(dá)式表示簽名元素的絕對路徑信息，而該種類型的攻擊會改變簽名元素的絕對路徑信息，接收方在根據(jù)安全策略文件中的絕對路徑信息指定的元素進(jìn)行驗證時，會出現(xiàn)摘要值的不匹配，導(dǎo)致簽名驗證失敗。

驗證互補(bǔ)(過濾器)方案中，由于過濾器只把簽名消息傳送給應(yīng)用邏輯，應(yīng)用邏輯處理的只能是簽名消息，而不會是攻擊信息。因此，此方案下的簽名不受該種攻擊類型的影響。驗證互補(bǔ)(位置指示器)方案中，接收方可以將通過位置指示器獲取的當(dāng)前SOAP消息中簽名元素的絕對路徑信息和消息發(fā)送前的絕對路徑信息進(jìn)行比較來發(fā)現(xiàn)該種攻擊。

由于該種類型的攻擊必然會改變簽名節(jié)點的位置，而在根據(jù)FastXPath表達(dá)式對簽名對象進(jìn)行引用驗證時，會出現(xiàn)摘要值的不匹配，導(dǎo)致簽名驗證失敗。因此，F(xiàn)astXPath方案可以檢測到。

該種類型的攻擊會改變DOM樹中Envelope、Body或者簽名元素的位置標(biāo)記。所以，標(biāo)記DOM樹中元素位置的方案可以通過這種改變檢測出該種攻擊。

SOAP Account方法能檢測到將偽造的頭元素添加到Envelope或Header元素中的攻擊，但不能檢測出將整個Envelope元素封裝后添加到Header子元素中的攻擊，因為這時SOAP Account中標(biāo)記的結(jié)構(gòu)信息并未改變。因此，不能確定SOAP Account方法對該種攻擊類型的檢測結(jié)果。

改進(jìn)的SOAP Account方法中，攻擊者如果只是封裝簽名消息添加到SOAP頭中，必然會導(dǎo)致簽名元素的父節(jié)點信息的改變，雖然層次信息在極少的情況下可能保持不變，但是能檢測到這種攻擊類型。攻擊者如果封裝簽名消息及其父節(jié)點并添加到SOAP頭中，在層次信息可能保持不變的極少情況下，不能檢測到這種攻擊類型。所以，不能確定對該種攻擊類型的檢測結(jié)果，但是它能檢測到大范圍的該種攻擊類型。

因此，針對封裝簽名消息添加到SOAP頭中的攻擊，安全策略、驗證互補(bǔ)、FastXPath和標(biāo)記DOM樹中元素位置方案能夠檢測到，可作為針對該種攻擊類型的安全應(yīng)對方案。但是，由于不能確定內(nèi)聯(lián)法的檢測結(jié)果，故內(nèi)聯(lián)法不能作為針對該種攻擊類型的安全應(yīng)對方案。

2.2 重定向攻擊

重定向攻擊是指攻擊者將SOAP消息的回復(fù)地址元素封裝到偽造的頭元素里，使其不被接收端的應(yīng)用邏輯處理，實現(xiàn)修改SOAP消息回復(fù)地址的攻擊行為。假設(shè)Header中簽名的頭元素為可選元素，接收方并不確定發(fā)送方是否指定了回復(fù)地址。這里主要是為了區(qū)別2.1節(jié)的安全策略，如果頭元素聲明為必須元素，2.1節(jié)的安全策略就能檢測到。

安全策略文件中可通過絕對XPath表達(dá)式“/Envelope/Header/ReplyTo”對元素進(jìn)行簽名引用(區(qū)別于2.1節(jié)的安全策略)。攻擊者如果將元素封裝到偽造的元素里，在進(jìn)行簽名驗證時，簽名引用中的絕對XPath表達(dá)式會指向一個空的節(jié)點集，必然出現(xiàn)摘要值的不匹配，導(dǎo)致簽名驗證失敗。

驗證互補(bǔ)(過濾器)方案中，過濾器只將簽名信息傳送給應(yīng)用邏輯，應(yīng)用邏輯處理的只能是簽名信息。所以，該方案不受該種攻擊類型的影響。驗證互補(bǔ)(位置指示器)方案中，接收方可以將通過位置指示器獲取的當(dāng)前SOAP消息中簽名元素的絕對路徑信息和消息發(fā)送前的絕對路徑信息進(jìn)行比較來發(fā)現(xiàn)該種攻擊。

由于該種類型的攻擊會改變簽名節(jié)點的絕對路徑信息，使用FastXPath表達(dá)式對簽名消息進(jìn)行引用驗證時，會指向一個空的節(jié)點集，出現(xiàn)摘要值的不匹配，導(dǎo)致簽名驗證失敗。因此，F(xiàn)astXPath方案可以檢測到。

該種攻擊會改變DOM樹中Envelope、Body或者簽名元素的位置標(biāo)記。所以，標(biāo)記DOM樹中元素位置的方案可以通過這種改變檢測出該種攻擊類型。

SOAP Account方法中，攻擊者如果只是封裝元素并添加到元素原來的位置，會改變元素的前驅(qū)和后繼關(guān)系，導(dǎo)致SOAP Account元素標(biāo)記的結(jié)構(gòu)信息的改變。這時，能檢測到。如果攻擊者將元素的父元素封裝到偽造的頭元素里添加在元素原來的位置，SOAP Account元素標(biāo)記的結(jié)構(gòu)信息并不會改變。這時，不能檢測到。所以，不能確定SOAP Account方法的檢測結(jié)果。

改進(jìn)的SOAP Account方法中，攻擊者如果封裝元素或者其父元素添加到SOAP頭中元素原來的位置，必然會導(dǎo)致簽名元素的父節(jié)點信息或者層次信息的改變。這時，能檢測到該種攻擊類型。然而，攻擊者如果封裝元素及其父元素并添加到SOAP體中，同時保持元素的層次信息不變。這時，不能檢測到該種攻擊類型。所以，不能確定對該種攻擊類型的檢測結(jié)果，但是它能檢測到大范圍的該種攻擊。

因此，針對重定向攻擊，安全策略、驗證互補(bǔ)、FastXPath和標(biāo)記DOM樹中元素位置方案能檢測到，可作為針對該種攻擊類型的安全應(yīng)對方案。但是，由于不能確定內(nèi)聯(lián)法的檢測結(jié)果，故不能作為針對該種攻擊類型的安全應(yīng)對方案。

2.3 多Security頭攻擊

SOAP消息中通過Header頭中的消息標(biāo)識符和Security頭中的時間戳元素來防止重放攻擊，但是消息標(biāo)識符和時間戳自身可能會被攻擊者修改[14]。多Security頭攻擊就是指攻擊者將原Security頭中的時間戳元素封裝在一個新的Security頭中并添加到Header頭中的攻擊(這里以時間戳元素為例)。消息標(biāo)識符和時間戳元素如果一個被修改，攻擊者就可以實現(xiàn)對SOAP消息的重放攻擊。針對元素的攻擊，情況同2.2節(jié)。這里主要討論檢測時間戳元素的攻擊。

安全策略文件中通過絕對的XPath路徑表達(dá)式“/Envelope/Header/Security/Timestamp”對元素進(jìn)行簽名引用，但是多Security頭攻擊并不會改變元素的絕對路徑，這時可通過為簽名元素的父節(jié)點Security添加一個role屬性值.../ultimateReceiver，使用XPath表達(dá)式“/Envelope/Header/Security[@role=“.../ultimateReceiver”]/Timestamp”來對簽名對象進(jìn)行引用，使簽名元素的父節(jié)點Security必須被接收端處理。攻擊者如果修改Timestamp元素的位置，會使XPath表達(dá)式指向一個空的節(jié)點集，導(dǎo)致簽名驗證失敗。

由于該種攻擊類型必然會改變SOAP Header的子元素數(shù)目以及兄弟元素之間的關(guān)系，所以，內(nèi)聯(lián)法能檢測到此種類型的攻擊。

驗證互補(bǔ)(過濾器)方案中，過濾器只將簽名消息傳送給應(yīng)用邏輯，應(yīng)用邏輯處理的只能是簽名消息，而不會是攻擊信息。所以，不受該種攻擊類型的影響。

FastXPath方法中使用FastXPath表達(dá)式“/Envelope/Header/Security[@role=“.../ultimateReceiver”]/Timestamp”來對Timestamp元素進(jìn)行簽名引用，而該種攻擊類型必然會改變簽名節(jié)點的位置，使FastXPath表達(dá)式指向一個空的節(jié)點集，導(dǎo)致簽名驗證失敗。所以，可以檢測到該種攻擊類型。

該種類型的攻擊必然會改變DOM樹中Envelope、Body或者簽名元素的位置標(biāo)記。所以，標(biāo)記DOM樹中元素位置方案可以通過這種改變檢測出該種攻擊。

驗證互補(bǔ)(位置指示器)方案中，由于此類攻擊中，攻擊者將簽名消息封裝到一個新的Security頭中并添加到Header頭中，并未改變簽名節(jié)點到文檔根節(jié)點的絕對路徑信息。這樣，攻擊前后的絕對路徑信息并未變化，接收方就不能通過絕對路徑信息的變化來檢測出該種攻擊。

因此，針對多Security頭攻擊，安全策略、內(nèi)聯(lián)法、驗證互補(bǔ)(過濾器)、FastXPath和標(biāo)記DOM樹中元素位置方案能夠檢測到，可作為針對該種攻擊類型的安全應(yīng)對方案。但是，驗證互補(bǔ)(位置指示器)方案不能檢測到，故不可作為針對該種攻擊類型的安全應(yīng)對方案。

2.4 修改上下文關(guān)聯(lián)信息的攻擊

修改上下文關(guān)聯(lián)信息的攻擊是指攻擊者修改簽名消息的上下文關(guān)聯(lián)信息，改變簽名消息的原始語義，從而達(dá)到篡改簽名的目的。上下文關(guān)聯(lián)信息是指與簽名消息在語義上相關(guān)的上下文關(guān)聯(lián)元素的內(nèi)容。

安全策略中通常使用絕對的XPath表達(dá)式指定簽名對象或者對簽名對象進(jìn)行引用，來保護(hù)簽名元素的位置信息，但是該種攻擊類型并不會改變簽名元素的位置信息，只是改變了簽名消息的上下文關(guān)聯(lián)元素的內(nèi)容以及簽名的原始語義，而根據(jù)安全策略并不能檢測到這些變化。因此，不能檢測到該種攻擊。

由于該種攻擊類型只是修改簽名元素的上下文關(guān)聯(lián)元素的內(nèi)容，并不會改變SOAP Account元素中標(biāo)記的任何結(jié)構(gòu)信息。所以，內(nèi)聯(lián)法不能檢測到。

攻擊者如果修改簽名消息的上下文關(guān)聯(lián)元素來實現(xiàn)重寫攻擊，表明應(yīng)用邏輯需要處理未簽名的內(nèi)容，而驗證互補(bǔ)(過濾器)方案只會將簽名消息傳送給應(yīng)用邏輯，顯然該方案不能滿足應(yīng)用邏輯的要求。所以，這里認(rèn)為該方案不能檢測到該種攻擊。驗證互補(bǔ)(位置指示器)中，應(yīng)用邏輯通過指示器獲取SOAP消息中簽名元素的絕對路徑信息，但是該種攻擊并不會導(dǎo)致絕對路徑信息的變化，所以不能通過路徑信息的變化檢測出該種攻擊。

該種攻擊類型并不會改變簽名節(jié)點的位置信息以及DOM樹中Envelope、Body或者簽名元素的位置標(biāo)記。所以，F(xiàn)astXPath以及標(biāo)記DOM樹中元素位置的方案都不能檢測出該種攻擊。

因此，針對修改簽名信息上下文關(guān)聯(lián)信息的攻擊，安全策略、內(nèi)聯(lián)法、驗證互補(bǔ)、FastXPath和標(biāo)記DOM樹中元素位置方案都不能檢測到，故均不能作為針對該種攻擊類型的安全應(yīng)對方案。

2.5 應(yīng)用場景分析

重放攻擊是指攻擊者將竊取的SOAP消息重復(fù)發(fā)送給接收方，以實現(xiàn)某種非法的目的。SOAP消息中通過消息標(biāo)識符元素和時間戳元素來防止重放攻擊，如果有一個元素被修改，就可能受到了重放攻擊。所以，阻止重放攻擊就是保護(hù)和元素不被攻擊。和元素可能受到的攻擊類型同重定向攻擊和多Security頭攻擊。如果某個方案能檢測到這兩種攻擊類型，就可以實現(xiàn)重放攻擊的檢測。

中間人攻擊是指攻擊者將截獲的SOAP消息修改后再轉(zhuǎn)發(fā)給接收方。常見的攻擊方式有：封裝簽名消息添加到SOAP頭中，在原簽名消息位置添加自己的攻擊信息，使應(yīng)用邏輯處理自己的攻擊信息；改變消息的請求或者回復(fù)地址，也就是重定向攻擊。如果能檢測到這兩種攻擊，就能有效地檢測中間人攻擊。

分析討論結(jié)果表明：已有方案都能應(yīng)用于有效地檢測中間人攻擊的場景中。除內(nèi)聯(lián)法及驗證互補(bǔ)(位置指示器)外，其他方案均能應(yīng)用于有效地檢測重放攻擊的場景中。而對于修改上下文關(guān)聯(lián)信息的攻擊方式，已有的方案都不能檢測到。

3 結(jié)束語

文中分析討論了針對各種常見XML重寫攻擊類型的安全應(yīng)對方案以及每種方案的應(yīng)用場景。對于封裝簽名消息添加到SOAP頭中的攻擊、重定向攻擊、多Security頭攻擊，這些檢測方案都能或部分檢測到。但是，對于修改上下文關(guān)聯(lián)信息的攻擊，已有方案都不能檢測到。為了增強(qiáng)針對XML重寫攻擊的檢測能力，還需展開進(jìn)一步的研究。

[1] McIntosh M，Austel P．XML signature element wrapping attacks and countermeasures[C]//Proceedings of the 2005 ACM workshop on secure web services.Fairfax,USA:ACM Press,2005:20-27．

[2] Web Services Policy 1.2-Framework (WS-Policy)[EB/OL]．2006-05-25.http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/．

[3] Della-Libera G，Hondo M，Janczuk T，et al．Web Services Security Policy language (WS-Security Policy)[EB/OL].2002.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wssecuritypolicy.asp.

[4] Bhargavan K，F(xiàn)ournet C，Gordon A，et al．TulaFale:a security tool for web services[C]//Proceedings of the 2nd international symposium on formal methods for components and objects.[s.l.]:[s.n.],2004:197-222．

[5] Bhargavan K，F(xiàn)ournet C，Gordon A．An advisor for web services security policies[C]//Proceeding of the secure web services workshop.[s.l.]:[s.n.],2005:1-9.

[6] 朱 云，徐 楓，宴 軻．基于XML重寫的SOAP安全[J]．信息工程大學(xué)學(xué)報，2013,14(5):634-640．

[7] Rahaman M A，Marten R，Schaad A．An inline approach for secure soap requests and early validation[C]//Proceeding of the Open Web Application Security Project Europe conference (OWASP).Leuven,Belgium:[s.n.],2006:1-15．

[8] Rahaman M A，Schaad A．Soap-based secure conversation and collaboration [C]//Proceedings of IEEE international conference on web services.Salt Lake City,Utah:IEEE,2007:471-480．

[9] Rahaman M A，Schaad A，Rits M．Towards secure soap message exchange in a SOA[C]//Proceedings of the 3rd ACM workshop on secure web services.Virginia,USA:ACM,2006:77-84．

[10] Benameur A，Kadir F A，F(xiàn)enet S．XML rewriting attacks:existing solutions and their limitations[C]//Proceeding of the international conference on applied computing.Algavre,Portugal:[s.n.],2008:94-102．

[11] Gajek S，Liao L J，Schwenk J．Breaking and fixing the inline approach[C]//Proceedings of the 2007 ACM workshop on secure web services.New York,NY,USA:ACM,2007:37-43．

[12] Gajek S，Jensen M，Schwenk J．Analysis of signature wrapping attacks and countermeasures[C]//Proceedings of IEEE international conference on web services.[s.l.]:IEEE,2009:575-582．

[13] Barhoom T S，Rasheed R S K．Position of signed element for SOAP message integrity[J].Journal of Computer Information Systems,2011,2(1):21-25．

[14] Kadir F A．RewritingHealer:an approach for securing web service communication[D]．Sweden:KTH Royal Institute of Technology,2008．

Study on Detecting Technique for XML Rewriting Attack

LIU Bao-long，YANG Wei，CHEN Hua

(School of Computer Science and Engineering，Xi’an Technological University，Xi’an 710021，China)

There is rewriting attack problem in the fine-grained XML digital signature now.There are several countermeasures can be used to detect XML rewriting attack.It makes a discussion on the security scheme to deal with the common rewriting attacks and the best application scenarios of the existing detection scheme based on the analysis and evaluation of the existing detection scheme.The study results show that security policy,verification complementary (filter),FastXPath and mark element position scheme in the DOM tree can detect the common attacks effectively and existing scheme can apply to detecting man-in-the-middle attack and repay attack effectively except for inline approach and verification complementary (position indicator) scheme.However,for attacks against modifying signature element context-sensitive information,all the existing detection scheme can’t detect.

XML rewriting attack;security policy;SOAP Account;verification complementary;FastXPath;redirection attack;multiple security header attack

2015-09-05

2015-12-10

時間：2016-05-25

教育部留學(xué)歸國人員科研啟動金資助項目(2013693)；面向重大裝備和能源化工的制造業(yè)信息化綜合應(yīng)用示范項目(2012BAF 12B04)；陜西省教育專項科研計劃項目(15KJ1350)

劉寶龍(1976-)，男，副教授，博士，研究方向為XML安全技術(shù)。

http://www.cnki.net/kcms/detail/61.1450.TP.20160525.1700.020.html

TP309.2

A

1673-629X(2016)06-0101-05

10.3969/j.issn.1673-629X.2016.06.022