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中文網其他相關文章!