一、xml外部實體注入
xml 外部實體注入漏洞也就是我們常說的 xxe 漏洞。xml 作為一種使用較為廣泛的數據傳輸格式，很多應用程序都包含有處理 xml 數據的代碼，默認情況下，許多過時的或配置不當的 xml 處理器都會對外部實體進行引用。
如果攻擊者可以上傳 XML 文檔或者在 XML 文檔中添加惡意內容，通過易受攻擊的代碼、依賴項或集成，就能夠攻擊包含缺陷的XML處理器。XXE 漏洞的出現和開發語言無關，只要是應用程序中對 xml 數據做了解析，而這些數據又受用戶控制，那么應用程序都可能受到 XXE 攻擊。本篇文章以 Java 程序為例給大家介紹 XXE 漏洞的成因及修復。XXE 漏洞詳細請見 CWE-611: Improper Restriction of XML External Entity Reference (‘XXE’)(http://cwe.mitre.org/data/definitions/611.html)。
二、XML外部實體注入
XXE 漏洞可能會用于提取數據、執行遠程服務器請求、掃描內部系統、執行拒絕服務攻擊和其他攻擊。業務影響主要取決于受影響的引用程序和數據保護需求。
2018年至今，CVE 中共有發布了 92 條漏洞信息與其相關。部分CVE如下：
| CVE-2018-8027 | Apache Camel 2.20.0 到 2.20.3 和2.21.0 Core 在 XSD 驗證處理器中存在 XXE 漏洞。 |
|---|---|
| CVE-2018-13439 | 微信支付 Java SDK 中的 WXPayUtil 類中存在XXE漏洞。 |
| CVE-2018-1000548 | 在版本號小于 14.3 的 Umlet 中，在文件解析中存在XML外部實體注入漏洞，可能導致機密數據泄露、拒絕服務、服務器端請求偽造。此攻擊可以通過特制的 UXF 文件進行攻擊。 |
| CVE-2018-1364 | IBM Content Bavigator 2.0 和 3.0 版本中在處理XML數據時，易受XML外部實體（XXE）攻擊。遠程攻擊者可以利用此漏洞暴露敏感信息或占用內存資源。 |
三、示例代碼
3.1 缺陷代碼
本節使用示例代碼來源為某開源支付 Java? SDK?(https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=11_1)，源文件名：WXPayUtil.java，文件路徑為：java-sdk-v3srcmainjavacomgithubwxpaysdk。?
在上述代碼可以看到在25行處數據通過?xmlToMap?形參傳入，數據未做任何過濾，且 XML 處理器也未做安全設置就在32行處對數據做了解析，而實際場景中，參數?strXML?也是受攻擊者控制的，這樣攻擊者可能通過構造惡意的?strXML?來進行 XXE 攻擊。
使用360代碼衛士對上述示例代碼進行檢測，可以在文件第32行檢出“有風險的XML外部實體注入”缺陷。如圖1所示：
圖1 ? 檢測出有風險的XML外部實體注入
3.2 修復代碼
在上述修復代碼中的第28行使用的是一個xml工具類WXPayXmlUtil，用于生成一個安全的xml處理器。而?WXPayXmlUtil?類中最為關鍵的是第16行，通過?setFeature?讓生成的 xml 處理器完全禁用?DTDS。通過圖2可以看出，360代碼衛士對修復后的代碼并未檢出缺陷。
圖2 ? XXE漏洞修復示例
四、如何避免XXE漏洞
常見的避免方法：
1. 盡可能使用簡單的數據格式（如：json），避免對敏感數據進行序列化；2. 及時修復或更新應用程序或底層操作系統使用的所有XML處理器和庫。同時，通過依賴項檢測，將SOAP更新到1.2版本或更高版本；3. 在應用程序的所有XML解析器中禁用XML外部實體和DTD進程，具體實現可以參考《OWASP Cheat Sheet ‘XXE Prevention’》(https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet)如下代碼是java應用程序中使用DocumentBuilderFactory解析xml時防范XXE漏洞的示例：4. 輸入校驗：在服務器端使用白名單進行輸入驗證和過濾，以防在XML文檔、標題或節點中出現惡意數據。5. 驗證XML和XSL文件上傳功能是否使用XSD驗證或其他類似驗證的方法來驗證上傳的XML文件6. DAST工具需要額外的手動步驟來檢查和利用XXE漏洞，而使用ASAT工具可以通過檢測依賴項和安全配置來發現XXE漏洞。
