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)。
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）攻擊。遠端攻擊者可以利用此漏洞暴露敏感資訊或佔用記憶體資源。 |
本節使用範例程式碼來源為某開源支付Java SDK (https:/ /pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=11_1)，來源檔案名稱：WXPayUtil.java，檔案路徑為：java-sdk-v3\src\main\java\com\ github\wxpay\sdk。
在上述程式碼可以看到在25行處資料透過 xmlToMap 形參傳入，資料未做任何過濾，且XML 處理器也未做安全設定就在32行處對資料做了解析，而實際場景中，參數 strXML 也是受攻擊者控制的，這樣攻擊者可能透過建構惡意的 strXML 來進行XXE 攻擊。
使用360程式碼衛兵對上述範例程式碼進行偵測，可以在檔案第32行檢出「有風險的XML外部實體注入」缺陷。如圖1所示：
圖1 偵測出有風險的XML外部實體注入
#在上述修復程式碼中的第28行使用的是一個xml工具類別WXPayXmlUtil，用於產生一個安全的xml處理器。而 WXPayXmlUtil 類別中最為關鍵的是第16行，透過 setFeature 讓產生的 xml 處理器完全停用 DTDS。透過圖2可以看出，360代碼衛士對修復後的程式碼並未檢出缺陷。
圖2 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應用程式中使用DocumentBuilderXXE漏洞的範例：
4. 輸入校驗：在伺服器端使用白名單進行輸入驗證和過濾，以防在XML文件、標題或節點中出現惡意資料。
5. 驗證XML和XSL檔案上傳功能是否使用XSD驗證或其他類似驗證的方法來驗證上傳的XML檔案
6. DAST工具需要額外的手動步驟來檢查和利用XXE漏洞，而使用ASAT工具可以透過偵測依賴項和安全性配置來發現XXE漏洞。
以上是XML外部實體注入漏洞的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
