摘要：它受眾廣，同時常用的解析器，例如，允許對進(jìn)行一些默認(rèn)處理。外部實體注入攻擊面對外部實體攻擊的脆弱點在于，解析器的庫往往都支持自定義的實體引用。

雖然JSON的出現(xiàn)實現(xiàn)了服務(wù)器與客戶端之間的“輕量級”數(shù)據(jù)交流，但是，作為另一種流行的可行方案，許多web服務(wù)API同時還是繼續(xù)支持XML。另外，除了web服務(wù)之外，XML也是許多使用XML schemas 實行數(shù)據(jù)交換的協(xié)議的基礎(chǔ)，例如RSS，Atom，SOAP，以及RDF等等，舉不勝舉。

XML無處不在：它存在于web應(yīng)用的服務(wù)器中，或者在瀏覽器中作為XMLHttpRequest的請求和應(yīng)答的格式，亦或在瀏覽器的擴展程序中。由于應(yīng)用廣泛，XML成為了吸引注入攻擊的目標(biāo)。它受眾廣，同時常用的XML解析器，例如libxml2，允許對XML進(jìn)行一些默認(rèn)處理。libxml2常在DOM、SimpleXML和XMLReader擴展中的PHP中使用。當(dāng)瀏覽器的XML交換很頻繁時，我們要考慮到，XML作為請求格式時，就算是認(rèn)證用戶，也有可能正通過跨站腳本攻擊發(fā)送攻擊者所編寫的XML。

面對XML外部實體攻擊（XXE）的脆弱點在于，XML解析器的庫往往都支持自定義的XML實體引用。你應(yīng)該熟悉，XML擁有表示>、<和&apos 等特殊標(biāo)記字符的實體，作為對一般實體的標(biāo)準(zhǔn)補充。同時XML允許用戶在XML文檔內(nèi)自定義實體，以此來擴展其標(biāo)準(zhǔn)實體集。這些自定義實體可以直接寫在可選的DOCTYPE中，而它們代表的擴展值則可引用一個外部資源。正是普通XML的這種支持自定義引用、可引用外部資源內(nèi)容的可擴展性，導(dǎo)致系統(tǒng)易受XXE的攻擊。通常，我們的系統(tǒng)絕不應(yīng)當(dāng)允許不受信任的輸入以無法預(yù)期的方式參與到系統(tǒng)交互中來，同時絕大大多數(shù)程序開發(fā)人員都不會考慮到XXE。因此值得我們特別注意。

例如，讓我們來試著定義一個新的自定義實體“harmless”。

 ]>

現(xiàn)在，包含這個實體定義的XML文檔可以在任何允許的地方引用&harmless;實體。

]>

    This result is &harmless;
 

XML解析器，例如PHP DOM，在解析這段XML時，會在加載完文檔后立即處理這個自定義實體。因此，請求相關(guān)文本時，會得到如下的返回：

This result is completely harmless

無疑，好處是，自定義實體可以用較短的實體名來代表重復(fù)的文本和XML。當(dāng)XML需要遵守特定的語法規(guī)范，或者需要自定義實體使編輯更為簡單時，這種方法并不少見。但是，考慮到遵守不信任外部輸入的原則，我們要特別小心地對待應(yīng)用程序中使用的所有XML，辨別它們的真正目的。下面的這個就肯定不是無害的輸入：

]>

    &harmless;

取決于請求的本地文件的內(nèi)容，某些內(nèi)容可用于擴充&harmless;實體，這些內(nèi)容可以從XML解析器中提取出來，包含在web應(yīng)用的輸出中，攻擊者看到它們，即會造成信息泄露。獲取的文件將會被解析成XML，除非避開某些可以觸發(fā)解析的特殊字符，而這限制了泄露的范圍。如果文件被解析為XML但并不包含有效的XML內(nèi)容，系統(tǒng)會報錯，這樣一來可以避免內(nèi)容泄露。但是，PHP中有一個巧妙的“技倆”，可以繞過這種范圍的限制，既使得攻擊者接收不到應(yīng)答，遠(yuǎn)程HTTP請求卻仍然可以影響web應(yīng)用。

PHP有三種常用的方法，用來解析和使用XML：PHP DOM、SimpleXML，以及XMLReader。這三種方法都需要使用libxml2擴展，也默認(rèn)啟用外部實體支持。這種默認(rèn)設(shè)置導(dǎo)致PHP在XXE面前很脆弱，而我們在考慮web應(yīng)用或XML應(yīng)用庫的安全性時，很容易疏忽這一點。

你也知道，XHTML和HTML5都可以被序列化為有效的XML，也就是說，某些XHTML頁面和被序列化的HTML5可以被解析為XML，例如，使用DOMDocument::loadXML()，而不是DOMDocument::loadHTML()時。這種XML解析方法在XEE注入的面前也很脆弱。注意，與XHTML DOCTYPES不同，libxml2目前甚至無法識別HTML5 DOCTYPE，因此無法讓其成為有效的XML。

文件內(nèi)容和信息泄露

在早前的一個信息泄露的例子中，我們注意到自定義實體可能引用一個外部文件。

]>

    &harmless;

這會把文件內(nèi)容擴展到自定義的&harmless;實體中。由于所有類似的請求都是在本地完成的，這使得該應(yīng)用有權(quán)限讀取的所有文件內(nèi)容都可能被泄露。只要應(yīng)用的輸出中包含了這個擴展了的實體，攻擊者就可以查看那些文件，包括沒有公開的文件。因這種方式而造成內(nèi)容泄露的文件是相當(dāng)有限的，只能是XML文件，和不會造成XML解析錯誤的文件。但是，PHP可以完全忽略這種限制。

 

]>

    &harmless;

PHP允許通過URI訪問PHP wrapper，這是一般文件系統(tǒng)函數(shù)，如file_get_contents()、require()、require_once()、file()、和copy()等，接受的協(xié)議之一。PHP wrapper支持一些過濾器，這些過濾器運行在給定的資源上，結(jié)果可以通過函數(shù)調(diào)用返回。在上述例子中，我們對想要讀取的目標(biāo)文件使用了convert.base-64-encode過濾器。

這意味著，攻擊者通過利用XXE的脆弱性，可以用PHP讀取任何可讀的文件，不論文本格式如何。攻擊者只需用base64將應(yīng)用輸出解碼，就可以毫無顧忌的分析一大堆非公開文件的內(nèi)容。盡管這本身不會直接傷害終端用戶或是應(yīng)用后臺，但是它能讓攻擊者了解目標(biāo)應(yīng)用，從而以最小的代價、最低的風(fēng)險發(fā)現(xiàn)應(yīng)用的其他弱點。

繞過訪問控制

訪問控制可以通過各種方法來實現(xiàn)。由于XXE攻擊是掛在web應(yīng)用后臺的，它無法使用當(dāng)前用戶會話產(chǎn)生任何影響，但是攻擊者仍然可以借助從本地服務(wù)器發(fā)送請求，來繞過后臺訪問控制。我們來看一下下面這個簡單的訪問控制：

if (isset($_SERVER["HTTP_CLIENT_IP"])
    || isset($_SERVER["HTTP_X_FORWARDED_FOR"])
    || !in_array(@$_SERVER["REMOTE_ADDR"], array(
        "127.0.0.1",
        "::1",
    ))
) {
    header("HTTP/1.0 403 Forbidden");
    exit(
        "You are not allowed to access this file."
    );
}

這段PHP和無數(shù)的類似代碼都用于限制特定PHP文件對本地服務(wù)器的訪問，如 localhost。但是，應(yīng)用前端的XXE脆弱性，正好為攻擊者提供了繞過訪問控制所需的憑證，因為XML解析器發(fā)出的所有HTTP請求都來自localhost。

]>

    &harmless;

如果只有本地請求可以查看日志，攻擊者就可以成功獲取日志。同樣的思路也適用于只接受本地請求的維護和管理接口。

拒絕服務(wù)（DOS）

幾乎所有可以控制服務(wù)器資源利用的東西，都可用于制造DOS攻擊。通過XML外部實體注入，攻擊者可以發(fā)送任意的HTTP請求，從而在恰當(dāng)?shù)臅r候耗盡服務(wù)器資源。

下文中還有一些其他的例子，通過XML實體擴展造成XXE攻擊，從而制造潛在的DOS攻擊。

這類攻擊十分“誘人“，但對它的防御也簡單的出奇。既然DOM、SimpleXML和XMLReader依賴于libxml2，我們可以簡單地利用libxml_disable_entity_loader()函數(shù)來禁止外部實體引用。與此同時，DOCTYPE中預(yù)定義的自定義實體卻不會受到影響，因為它們并沒有使用任何需要文件系統(tǒng)操作或發(fā)送HTTP請求的外部資源。

$oldValue = libxml_disable_entity_loader(true);
$dom = new DOMDocument();
$dom->loadXML($xml);
libxml_disable_entity_loader($oldValue);

在所有涉及通過字符串、文件或者遠(yuǎn)程URI來加載XML時，都需要使用這些操作。

當(dāng)應(yīng)用程序及其大部分請求都不需要外部實體時，你可以簡單地從全局禁掉外部資源加載。大多數(shù)時候，這比找出所有的XML加載實例來逐個操作要更好。記住，許多庫天生自帶XEE脆弱性：

libxml_disable_entity_loader(true);

每次需要臨時允許加載外部資源時，加載完后切記再把這里設(shè)為TRUE。例如，在將Docbook XML轉(zhuǎn)換為HTML時，所使用的XSL樣式就是依賴于外部實體的，這里需要外部實體，但是是無害的。

但是，libxml2函數(shù)絕不是"萬能鑰匙"。我們需要確認(rèn)，其他用于解析或處理XML的擴展和PHP庫的引用外部實體的功能，都處于關(guān)掉狀態(tài)。

如果不能通過上述方法來開關(guān)外部實體引用，你還可以檢查一下XML文檔是否聲明了DOCTYPE。如果聲明了，同時禁掉了外部實體，則可以簡單地丟棄XML文檔，拒絕可能造成解析器脆弱性的不受信任的XML訪問，同時將這種行為記錄為一次可能的攻擊。我們需要將這種行為記錄下來，因為除此之外不會有任何系統(tǒng)報錯記錄?？梢栽谌粘］斎腧炞C中進(jìn)行這項檢查。但是，這種方法并不理想，筆者還是強烈建議從源頭上解決外部實體的問題。

/**

Attempt a quickie detection

*/

$collapsedXML = preg_replace("/[:space:]/", "", $xml);
if(preg_match("/

   throw new InvalidArgumentException(
       "Invalid XML: Detected use of illegal DOCTYPE"
   );

}

同時，值得注意的是，當(dāng)我們懷疑一段數(shù)據(jù)有可能是某個攻擊的結(jié)果時，最好的方法是丟棄它，而不是繼續(xù)使用它。既然它已經(jīng)表現(xiàn)出了危險，為什么還要繼續(xù)使用它呢？因此，將上述兩個步驟合并起來，我們可以在無法丟棄數(shù)據(jù)時（例如第三方的庫），通過主動跳過壞數(shù)據(jù)起到保護作用。之所以我們更愿意完全丟棄這些數(shù)據(jù)，還因為上文提到過的一個理由：libxml_disable_entity_loader()不會將自定義實體完全禁掉，只有引用外部資源的才會被禁掉。因此這仍有可能導(dǎo)致一個被稱為XML實體擴展的注入攻擊。在下文中我們會提到這種攻擊。

原文地址：[Injection Attacks](http://phpsecurity.readthedocs.org/en/latest/Injection-Attacks.html#examples-of-xml-external-entity-injection
)

本文系 OneAPM 工程師編譯整理。OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)，能幫助企業(yè)用戶和開發(fā)者輕松實現(xiàn)：緩慢的程序代碼和 SQL 語句的實時抓取。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方博客。

本文轉(zhuǎn)自 OneAPM 官方博客