邱永哲



摘 要:為提高Web應用程序接口的安全性,文章介紹了一種基于XML外部實體的注入漏洞-XXE漏洞。通過列舉該漏洞的一些攻擊方式及其造成的危害,能對程序開發者起到警示作用,最后給出了該漏洞的防御方法,對安全實現Web應用程序的接口提供了參考。
關鍵詞:Web應用程序;接口;XML;注入漏洞
當前,伴隨著云計算的蓬勃發展,互聯網應用正逐步邁向微服務化、容器化、接口化,互聯網入口也正在從傳統的PC向種類繁多的智能設備和IoT設備轉移。因此,隨之帶來的網絡安全問題也愈發嚴峻,引起眾多政府組織的關注[1]。2017年4月,開放式Web應用程序安全項目發布了2017年Web安全十大問題,首次將“未受有效保護的應用程序的調用接口( Application Programming Interface,API)”列入了OWASP Top 10,指出了應用程序接口存在易受攻擊的風險。常見的應用程序接口之間數據傳遞的格式有XML和JSON等,如果在這些傳遞數據的過程中未對接口進行保護,將造成服務器被攻擊的嚴重安全事故[2]。本文在XML的基礎上介紹了一種較為嚴重的注入漏洞-XXE漏洞,并針對該漏洞列舉了一些攻擊手段和防御方法,為應用程序接口的安全實現與開發提供了參考。
1 XXE漏洞簡介
1.1 XML基礎
XML是一種標記語言,目前被廣泛地用來作為跨平臺之間交互數據的形式,主要針對不同的數據內容,通過不同的格式化描述手段完成最終的形式表達[3]。XML能定義數據的結構、存儲信息,例如將小張發送給小李的短信存儲為XML格式:
<?xml version=" 1.0"?>
如圖l所示,一個完整的XML文檔應當包括XML聲明、文檔元素,有時也包括文檔類型定義(Document TypeDefinition, DTD)。
DTD可以將它看作是一個或者多個XML文檔的模板,在這里可以定義XML文件中的元素、元素的屬性、元素的排列方式、元素包含的內容等。DTD文檔類型定義由4個關鍵字組成:元素(Element)、屬性(Attribute),實體( Entity)、注釋(Comments)。XXE漏洞就是由DTD中的“實體”引發[4]。
1.2 XXE漏洞原理
在XML l.0標準當中首次引入了“實體(Entity)”的概念,其作用類似于Word當中的“宏”。實體標識符的定義方式分為兩種,一種是在DTD中內部聲明實體:
另一種是在DTD中引入外部實體:
或者:
其中,外部實體可以訪問存儲在本地或者遠程的文件,因此XML文檔在處理DTD定義中的外部實體時,如不做好防護,將產生信息泄露、SSRF等漏洞。這也被叫作是XXE(XML External Entity injection)漏洞,即XML外部實體注入。
對于XXE漏洞的測試,可以使用DNS帶外查詢的方式來進行驗證,例如某服務器能處理XML格式的請求數據,可將如下PoC發送給服務器進行漏洞驗證:
<?xml version=" 1.0"?>
]> 借助XXE漏洞,攻擊者能夠實現對服務器的任意文件讀取、拒絕服務攻擊、代理掃描內網等。但是不同的XML解析器對外部實體的處理規則不同,例如在PHP中常用來處理XML數據的函數有simplexml_load_string和expat庫中的xml_parse,xml_parse函數默認情況下不會解析DTD中的外部實體,但simplexml_load_string默認會解析外部實體導致XXE。除PHP以外,Java、Python平臺中處理XML的函數都可能會產生XXE漏洞。 2 XXE漏洞利用 2.1任意文件讀取 任意文件讀取是XXE漏洞最常見的利用方式,本文在Linux平臺下搭建了基于docker容器的測試環境來測試演示該漏洞的攻擊過程[5]。 首先使用docker容器創建Apache+PHP架構服務器,隨后在服務器web目錄中創建包含有XXE漏洞的PHP文件simplexml_load_string.php,內容為: <?php $data = file_get_content s ( 'php://input ' ) $xml = simplexml_load_string($data); ?> 即在該文件中使用PHP的simplexml_load_string函數來接收處理XML數據。接下來使用請求構造工具Postman發送以下的XML請求: <?xml version=" 1.0" encoding=" utf-8"?>
請求響應結果如圖2所示,可以看到這里使用file協議成功讀取到了服務器文件/etc/passwd,造成了服務器文件信息泄露,利用該方法還有可能讀取到服務器中存放的數據庫密碼、SVN服務器密碼等其他敏感信息。
2.2服務端請求偽造
在某些情況下服務器端存在XXE漏洞,但只能使用http協議通過帶外查詢檢測,此時該XXE漏洞被稱為BlindXXE。由于無法使用file協議進行文件讀取,Blind XXE無法帶來更大的攻擊面,但是如果能結合SSRF服務器端請求偽造,往往能發揮至關重要的作用。
例如某企業一臺處于網絡邊界的Apache服務器存在Blind XXE漏洞,該服務器使用雙網卡連接了企業內部網絡10.4.10.0/24,企業內網有一臺未授權即可訪問的Redis服務器10.4.10.7,如果這臺服務器未做好SSRF防護,那么此時就可以利用這枚Bind XXE漏洞直接發起對內網Redis服務器的攻擊:
<?xml version=" 1.0"?>
<!ENTITY b SYSTEM“http://123.123.123.123/ gopher.php”> ]> 其中123.123.123.123為攻擊者的服務器,gopher.php的內容為: <?php header(Location: gopher://10.4.10.7:6379/ 一*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%Oa$60%Od%Oa%Oa%Oa*/1 **** bash—i>&/dev/tcp/12 3.123.123.12 3/77 77 0>&1%Oa%Oa%Od%Oa≠4%Od%Oa$ 6% Od% Oaconfig% Od% Oa$3%Od% Oadir% Od% Oa$16% Od%Oa/var/s pool/cron/% Od% Oa*4% Od% Oa$ 6% Od% Oaconfig%0d% Oa$3% Od% Oaset% Od% Oa$ 10% Od% Oadbfilename% Od%0a$ 4% Od%0 aroot%0d% Oa* 1%Od% Oa$4%0d% Oas ave%0d%0a)?> 這時候攻擊者將直接獲得內網Redis服務器的權限進而對企業內網進行進一步滲透。可見此時Blind XXE通過與SSRF的結合極大地拓展了攻擊面,為攻擊者進一步的突破創造了條件。 2.3拒絕服務攻擊 由于XXE漏洞是由服務器端接收并處理用戶惡意數據造成,因此攻擊者還可以通過構造復雜的邏輯來消耗服務器的運算資源,最終導致拒絕服務攻擊。例如向一臺存在XXE漏洞的服務器發送如下的XML數據: <?xml version="1.0"?> <101z>&1019;
2.4其他危害
事實上,XXE漏洞除了上述一些攻擊利用方式之外,也可能會出現更多的攻擊方式。XXE漏洞在不同語言和平臺上可能支持的協議如圖3所示。
而對于PHP應用程序來說,如果安裝了更多PHP的擴展例如expect協議,那么XXE漏洞將直接可以被轉化為命令執行漏洞。
3 XXE漏洞防御方法
對XXE漏洞的防御要做到兩點。
(l)過濾用戶提交的XML數據,禁止出現<!DOCTYPE、 <!ENTITY. SYSTEM和PUBLIC等關鍵字。
(2)在源代碼層面禁止使用外部實體。
#PHP
libxml disable_entity_loader(true);
#Java
DocumentbuilderFactory dbf =DocumentbuilderFactory.newlnstance();
dbf setExpandEntityRe ferences (false);
#Python
from lxml import etree
xmIData=etree.parse(xmISource. etree.XMLParse (resolve_entities=False》
[參考文獻]
[1]維基百科.XML[EB/OL].( 2017-12-15)[2018-02-08].https://zh.wikipedia.org/wiki/XML.
[2]維基百科.文檔類型定義[EB/OL]( 2017-12-26) [2018-02-08] .https://zh.wikipedia.org/、viki/文檔類型定義
[3]Timothy D.Mo-gan, Omar AI Ibrahim.XML Schema. DTD. and Entity Attacks -A Compendium of Known Techniques[EB/OL]( 2017-
10~25)[2018 - 02- 08].https://、vww.vsecurity.c om//download/p aper s/XMLDTDEntit yAttacks .pdf.
[4]維基百科.Billion laughs attack[EB/OL].( 2017-11-15) [2018-02-08] .https://enrvikipedia.org/、viki/Billion
laughs
attack.
[5]騰訊安全應急響應中心.未知攻焉知防-XXE漏洞攻防[EB/OL]( 2018-01-10) [2018-02-08] .https://security.tencent.com/index.p hp/blog/
msg/69.