增強ebXML的安全性2——內容攻擊(圖)

2019-11-18 12:48:43

字體：大中小

來源：轉載

供稿：網友

　　本文是有關ebxml安全性的兩篇文章中的第二篇。在第一篇文章消息交換中，我們分析了消息層安全性和ebXML消息的安全性策略。即，第一篇文章關注這樣一個事實，實際的有效負載可以通過簽名和加密來提供持久安全性、數據隱私和ebMS消息審計能力。正如先前所討論的，這種有效負載保護超越了傳輸層機制（例如SSL或者TLS）所提供的級別。這種類型的消息層安全性屬于trust enablement類，該類答應消息包含已簽名和加密的有效負載，而不考慮傳輸。
　　
　　本文的主要目的是關注一種新的內容威脅類別，稱為XML內容攻擊。這些攻擊依靠的是XML有效負載的可執行性特性和ebMS消息中代碼插入和強制分析嘗試的容量。正如我們所看到的，即使是標題加密、簽名、傳輸層安全性等對策也不足以確保不受這些類型的業務威脅的攻擊。
　　
　　定義XML內容攻擊
　　
　　XML 內容攻擊是任何類型的基于XML的內容攜帶的威脅，該威脅具有以下一種或者幾種能力：
　　
　　導致處理的應用程序崩潰或者發生故障，出現拒絕服務狀態（DoS）。
　　
　　強制處理的應用程序執行惡意的或者多余的代碼，或者強制處理應用程序之后的任何下游實體執行惡意的或者多余的代碼。
　　
　　為了了解如何保護應用程序不受XML內容攻擊的破壞，我們首先必須了解在處理XML（非凡情況下，還有ebMS）時將發生什么事。
　　
　　普通ebMS消息處理
　　
　　當傳輸并隨后處理ebMS消息的時候，即使使用經過加密的有效負載，仍然存在未加密的外部結構和元數據始終需要處理。這種外部結構是SOAP標題和正文，以及ebMS消息標題和清單。此處發生的處理操作在通常情況中包含XML分析和XML語法驗證。
　　
　　分析步驟是所有類型的XML處理的基本先決條件，第二個步驟涉及到schema驗證，該步驟確保在將消息傳遞到下游實體之前符合必要的SOAP和ebMS規范。通過使用驗證分析程序，一些實現可以同步執行分析和驗證。
　　
　　schema驗證步驟涉及到使用W3C兼容的schema，以驗證收到的XML消息的語法。對ebMS來說，主要的SOAP消息依靠兩種schema，SOAP v1.1結構和標題，以及ebMS 2.0定義的清單擴展。圖1是相關的步驟簡圖。
　　　增強ebXML的安全性2——內容攻擊(圖)

圖1.典型ebMS標準的XML處理配置。
　　
　　在圖1中，ebMS 2.0消息進入貿易合作伙伴的B2B網關，并在網關中接受分析和隨后驗證。圖中還說明了B2B服務器依靠兩種schema定義（XSD文檔），SOAP v1.1 schema和ebMS 2.0 schema。兩種schema都可以在schema驗證過程中使用，以執行內容模型檢查和防止異常請求的破壞。
　　
　　正如我們將在下面章節中看到的那樣，這種標準配置對于XML內容攻擊來說是存在漏洞的，即使遵循schema驗證步驟。
　　
　　ebMS 2.0內容攻擊
　　
　　大多數XML安全性方面的新手會認為使用schema驗證步驟防止XML內容攻擊的破壞綽綽有余。例如，schema驗證要求根據標準schema精確地檢查ebMS 2.0消息。假如發送了任何類型的異常請求，schema驗證步驟將失敗，并且消息將立即被拒絕。不幸的是，這種推理不正確，因為在標準schema（包括ebMS 2.0）中使用了可擴展性點。
　　
　　在schema中，extensibility point是一個通用術語，指開放內容模型。開放內容模型就是答應將來自外部名稱空間的內容存放在XML有效負載中，同時仍可以維護schema有效性。換句話說，消息根據外來內容的存在，使用標準schema來維護有效性。在schema中存在可擴展性點的原因是schema有效性不代表安全特性，而代表語言語法驗證特性。當語言具有一種開放內容模型的時候，這主要說明語言的有效實例可以包含意外的或者外來的內容。
　　
　　開放語言內容模型答應schema具有可擴展性和前瞻性。不幸的是，正是這種可擴展性對于希望使用XML實現安全業務交易的合作伙伴來說是一個巨大的、開放性的漏洞。
　　
　　為了查看擴展點是如何使用ebMS，有必要首先看看根據ebMS 2.0 schema定義的內容模型。以下示例和定義基于這一位置提供的標準ebMS 2.0 schema：
　　
　　http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
　　
　　ebMS 2.0內容模型
　　
　　如前文所述，假如我們需要了解其擴展點是如何操作的，則我們必須研究ebMS 2.0內容模型。要做的第一件事情是查看ebMS 2.0 schema是如何定義的。對啟動程序來說，因為ebMS依靠于SOAP v1.1，所以schema定義是根據SOAP擴展點定義的。尤其是，元素結構的BNF語法式樣視圖如清單1所示。該結構使用標準的基數符號（cardinality symbol），即，星號（*）代表零或者多，問號（?）代表零或者一，加號（+）代表一或者多，不存在只代表一項的符號。為了提高透明度，這里已省略名稱空間。
　　
　　清單1. SOAP/ebMS元素結構
　　
　　<Envelope>
　　<Header>
　　<MessageHeader>
　　<From>
　　<To>
　　<CPAId>
　　<ConversationId>
　　<Service>
　　<Action>
　　<MessageData>
　　(<DuplicateElimination>) ?
　　(<Description>)　　　　　*
　　</MessageHeader>
　　<Header>
　　<Body>
　　(<Manifest>
　　(<Reference>　　　　+
　　(<Schema>)　　　　*
　　(<Description>)　 *
　　</Reference )　　　+
　　</Manifest> )　　　　 ?
　　<Body>
　　</Envelope>
　　前一內容模型說明了ebMS的外部結構。ebMS消息的Schema有效實例需要至少具有所示的結構和基數規則（cardinality rule）。清單1全面地描述了維護schema有效性所需的最低要求，但是沒有說明各種擴展點。ebMS中的很多元素schema類型定義答應插入任意內容。例如，考慮如清單2所示的以下兩種Manifest元素示例。同樣，為了提高透明度，這里已省略名稱空間。
　　
　　清單2：兩種Schema有效的Manifest元素
　　
　　ebMS Manifest Schema有效實例A
　　
　　<Manifest id="Manifest" version="2.0">
　　<Reference id="pay01" xlink:href="cid:payload-1"
　　xlink:role="http://regrep.org/gci/purchaseOrder">
　　<Schema location="http://foo.com/po.xsd" eb:version="2.0"/>
　　<Description>
　　Purchase Order for 100,000 widgets
　　</eb:Description>
　　</eb:Reference>
　　</eb:Manifest>
　　ebMS Manifest Schema有效實例B
　　<Manifest id="Manifest" version="2.0">
　　<Reference id="pay01" xlink:href="cid:payload-1"
　　xlink:role="http://regrep.org/gci/purchaseOrder">
　　<Schema location="http://foo.com/po.xsd" eb:version="2.0"/>
　　<Description>
　　Purchase Order for 100,000 widgets
　　</eb:Description>
　　<Garbage a="1" a="2" a="3" a="4" a="5" a="6" ...>
　　<Garbage>
　　<Garbage>
　　<Garbage>
　　<Garbage>
　　<Garbage>
　　<Garbage>
　　
　　</Garbage>
　　</Garbage>
　　</Garbage>
　　</Garbage>
　　</Garbage>
　　</eb:Reference>
　　</eb:Manifest>
　　在這一點上，非常明顯，清單2所示的ebMS消息B中可能存在外來的危險內容。此處添加的外部內容只是一個小小的示例，實際上數百兆字節的外部數據可能會用于連接XML處理資源。此外，假如添加了希奇但格式完整的內容（例如插入深層嵌套的屬性或者代碼），則可以利用某些分析程序中的單點弱點。
　　
　　讀者在此也許會提出異議，即注重到，由于XML Signature的作用，整個標題都可以受到保護，這使插入任意XML內容變得不可能。該參數無效的原因是文檔必需在簽名得到驗證之前進行分析。在使用傳統簽名的二進制格式文檔中，這種情況可能始終不會出現；簽名可能首先被處理。但是，在XML的情況中，XML Signature本身就是XML。因此，首先進行的就是XML分析，這意味著在簽名驗證進行之前，分析程序最終必須處理文檔的整個節點集，所以攻擊將在簽名驗證過程開始之前或者簽名驗證過程進行中開始，而永遠不會在簽名驗證過程完成之后開始。
　　
　　清單2的要點是schema驗證和XML Signature都不能防止如實例B所示的外部內容的破壞。其原因在于ebMS 2.0消息規范中的可擴展點。尤其是，Reference元素被定義為可擴展，并答應以一種毫無限制的方式添加來自外部名稱空間的任何元素。用于提供這種可擴展性的schema定義機制被稱為any元素，在使用該元素的schema中它是主要的安全性漏洞之一。請參見清單3以獲取Reference的schema定義片斷。
　　
　　清單3：Reference元素的Schema定義
　　
　　<element name="Reference">
　　<complexType>
　　<sequence>
　　<element ref="tns:Schema" minOccurs="0" maxOccurs="unbounded" />
　　<element ref="tns:Description" minOccurs="0" maxOccurs="unbounded" />
　　<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
　　</sequence>
　　<attribute ref="tns:id" />
　　<attribute ref="xlink:type" fixed="simple" />
　　<attribute ref="xlink:href" use="required" />
　　<attribute ref="xlink:role" />
　　<anyAttribute namespace="##other" processContents="lax" />
　　</complexType>
　　</element

上一篇：實用技巧分析——JXPATH實用講解

下一篇：用消息交換增強ebXML的安全性