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

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

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

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

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

 ]>

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

]>

    This result is &harmless;
 

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

This result is completely harmless

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

]>

    &harmless;

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

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

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

文件內容和信息泄露

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

]>

    &harmless;

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

 

]>

    &harmless;

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

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

繞過訪問控制

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

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和無數的類似代碼都用于限制特定PHP文件對本地服務器的訪問，如 localhost。但是，應用前端的XXE脆弱性，正好為攻擊者提供了繞過訪問控制所需的憑證，因為XML解析器發出的所有HTTP請求都來自localhost。

]>

    &harmless;

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

拒絕服務（DOS）

幾乎所有可以控制服務器資源利用的東西，都可用于制造DOS攻擊。通過XML外部實體注入，攻擊者可以發送任意的HTTP請求，從而在恰當的時候耗盡服務器資源。

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

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

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

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

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

libxml_disable_entity_loader(true);

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

但是，libxml2函數絕不是"萬能鑰匙"。我們需要確認，其他用于解析或處理XML的擴展和PHP庫的引用外部實體的功能，都處于關掉狀態。

如果不能通過上述方法來開關外部實體引用，你還可以檢查一下XML文檔是否聲明了DOCTYPE。如果聲明了，同時禁掉了外部實體，則可以簡單地丟棄XML文檔，拒絕可能造成解析器脆弱性的不受信任的XML訪問，同時將這種行為記錄為一次可能的攻擊。我們需要將這種行為記錄下來，因為除此之外不會有任何系統報錯記錄。可以在日常輸入驗證中進行這項檢查。但是，這種方法并不理想，筆者還是強烈建議從源頭上解決外部實體的問題。

/**

Attempt a quickie detection

*/

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

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

}

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

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

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

本文轉自 OneAPM 官方博客