XML重寫攻擊檢測技術研究

劉寶龍，楊 威，陳 樺

(西安工業大學 計算機科學與工程學院，陜西 西安 710021)

XML重寫攻擊檢測技術研究

劉寶龍，楊 威，陳 樺

(西安工業大學 計算機科學與工程學院，陜西 西安 710021)

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

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

0 引 言

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

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

1.1 安全策略

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

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

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

1.2 內聯法

(1)SOAP Account方法。

SOAP Account方法[6-9]通過添加一個新的SOAP Account元素來標記SOAP消息的結構信息，這個元素在消息創建時被添加進來。

SOAP Account元素中包含的SOAP結構信息如下：

·Envelope元素的子元素個數；

·SOAP Header子元素的個數；

·簽名中引用的個數；

·每個簽名對象的后繼和前驅關系。

(2)改進的SOAP Account方法。

Benameur等對SOAP Account方法進行了改進[10]，修改了SOAP Account元素中標記的結構信息。

改進的SOAP Account方法中，SOAP Account元素包含的SOAP信息如下：

·標記簽名元素的層次信息；

·標記簽名元素的父節點名稱；

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

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

1.3 驗證互補方案

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

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

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

1.4 FastXPath方案

該方案中使用FastXPath表達式對簽名對象進行引用，以標記文檔根節點到簽名節點的絕對路徑信息，通過固定簽名節點的位置，來實現檢測XML重寫攻擊的目的[12]。

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

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

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

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

2 針對常見攻擊的安全應對方案

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

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

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

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

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

由于該種類型的攻擊必然會改變簽名節點的位置，而在根據FastXPath表達式對簽名對象進行引用驗證時，會出現摘要值的不匹配，導致簽名驗證失敗。因此，FastXPath方案可以檢測到。

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

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

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

因此，針對封裝簽名消息添加到SOAP頭中的攻擊，安全策略、驗證互補、FastXPath和標記DOM樹中元素位置方案能夠檢測到，可作為針對該種攻擊類型的安全應對方案。但是，由于不能確定內聯法的檢測結果，故內聯法不能作為針對該種攻擊類型的安全應對方案。

2.2 重定向攻擊

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

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

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

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

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

SOAP Account方法中，攻擊者如果只是封裝元素并添加到元素原來的位置，會改變元素的前驅和后繼關系，導致SOAP Account元素標記的結構信息的改變。這時，能檢測到。如果攻擊者將元素的父元素封裝到偽造的頭元素里添加在元素原來的位置，SOAP Account元素標記的結構信息并不會改變。這時，不能檢測到。所以，不能確定SOAP Account方法的檢測結果。

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

因此，針對重定向攻擊，安全策略、驗證互補、FastXPath和標記DOM樹中元素位置方案能檢測到，可作為針對該種攻擊類型的安全應對方案。但是，由于不能確定內聯法的檢測結果，故不能作為針對該種攻擊類型的安全應對方案。

2.3 多Security頭攻擊

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

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

由于該種攻擊類型必然會改變SOAP Header的子元素數目以及兄弟元素之間的關系，所以，內聯法能檢測到此種類型的攻擊。

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

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

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

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

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

2.4 修改上下文關聯信息的攻擊

修改上下文關聯信息的攻擊是指攻擊者修改簽名消息的上下文關聯信息，改變簽名消息的原始語義，從而達到篡改簽名的目的。上下文關聯信息是指與簽名消息在語義上相關的上下文關聯元素的內容。

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

由于該種攻擊類型只是修改簽名元素的上下文關聯元素的內容，并不會改變SOAP Account元素中標記的任何結構信息。所以，內聯法不能檢測到。

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

該種攻擊類型并不會改變簽名節點的位置信息以及DOM樹中Envelope、Body或者簽名元素的位置標記。所以，FastXPath以及標記DOM樹中元素位置的方案都不能檢測出該種攻擊。

因此，針對修改簽名信息上下文關聯信息的攻擊，安全策略、內聯法、驗證互補、FastXPath和標記DOM樹中元素位置方案都不能檢測到，故均不能作為針對該種攻擊類型的安全應對方案。

2.5 應用場景分析

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

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

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

3 結束語

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

[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，Fournet 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，Fournet 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]．信息工程大學學報，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，Fenet 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

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

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

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