摘要：雖說可以通過上述方式進(jìn)行防御，遠(yuǎn)程實(shí)體擴(kuò)展通過使解析器發(fā)出遠(yuǎn)程請(qǐng)求來獲得被引用實(shí)體的擴(kuò)展值來進(jìn)行攻擊。返回結(jié)果將自行定義其他解析器必須另行請(qǐng)求的外部實(shí)體。

XMl Entity Expansion（攻擊）某種程度上類似于 XML Entity Expansion，但是它主要試圖通過消耗目標(biāo)程序的服務(wù)器環(huán)境來進(jìn)行DOS攻擊的。這種攻擊基于XML Entity Expansion實(shí)現(xiàn)，通過在XML的DOCTYPE中創(chuàng)建自定義實(shí)體的定義實(shí)現(xiàn)，比如，這種定義可以在內(nèi)存中生成一個(gè)比XML的原始允許大小大出很多的XML結(jié)構(gòu)，來使這種攻擊得以耗盡網(wǎng)絡(luò)服務(wù)器正常有效運(yùn)行的必需內(nèi)存資源。這種攻擊方式同樣適用于HTML5的XML序列化功能模塊，該模塊當(dāng)前還不能被libxml2擴(kuò)展包識(shí)別為HTML。

要擴(kuò)展XML自定義實(shí)體以達(dá)到預(yù)期的耗盡服務(wù)器資源效果有好幾種方式。

通用實(shí)體擴(kuò)展攻擊同樣被稱為“Quadratic Blowup Attack”，使用這種方式時(shí)，自定義實(shí)體被定義為一個(gè)極長的字符串。當(dāng)文件中大量使用這個(gè)實(shí)體時(shí)，該實(shí)體在每次調(diào)用時(shí)都會(huì)進(jìn)行擴(kuò)展，生成一個(gè)大幅超出原XML所需RAM大小的XML結(jié)構(gòu)。

]>

    Now include &long; lots of times to expand
    the in-memory size of this XML structure
    &long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    Keep it going...
    &long;&long;&long;&long;&long;&long;&long;...

通過平衡自定義實(shí)體字符串大小和文檔主體內(nèi)使用實(shí)體數(shù)量，可以創(chuàng)建一個(gè)擴(kuò)展至占用服務(wù)器可預(yù)測RAM空間大小的XML文檔或字符串。通過這樣重復(fù)請(qǐng)求來占用服務(wù)器RAM，就可以發(fā)動(dòng)一次成功的拒絕服務(wù)攻擊。該方式的缺陷是，由于產(chǎn)生內(nèi)存消耗效果是基于簡單數(shù)乘的，因此初始XML文檔或字符串本身需要足夠大。

通用實(shí)體擴(kuò)展攻擊需要足夠大的XML輸入數(shù)據(jù)量，而遞歸實(shí)體擴(kuò)展攻擊的平均輸入字節(jié)能產(chǎn)生更強(qiáng)力的攻擊效果。這種攻擊方式依賴于XML解析器來解析，從而完成小實(shí)體集的指數(shù)級(jí)增長。通過這種指數(shù)爆炸性增長方式，一個(gè)比通用實(shí)體擴(kuò)展攻擊使用小得多的輸入數(shù)據(jù)量實(shí)際可增長得極大。因此這種方式被稱為“XML Bomb”或是“Billion Laughs Attack”也是十分恰切的。

    
    
    
    
    
    
]>

    Explode in 3...2...1...&boom;

XML Bomb攻擊并不需要可能會(huì)被程序限制的大量XML數(shù)據(jù)輸入。實(shí)體集像這樣指數(shù)倍增長，最終形成的擴(kuò)展后文本大小是初始 &x0實(shí)體值的2的100次方倍。這著實(shí)是一個(gè)龐大且毀滅性超強(qiáng)的炸彈！

常規(guī)和遞歸實(shí)體擴(kuò)展攻擊都依賴于XML文檔類型定義中定義在本地的實(shí)體，但是攻擊者同樣可以進(jìn)行外部實(shí)體定義。這很顯然需要XML解析器能夠像我們之前在描述XML外部實(shí)體注入式攻擊（XXE）時(shí)遇到的那樣，發(fā)起遠(yuǎn)程HTTP請(qǐng)求。而拒絕這種請(qǐng)求對(duì)你的XML解析器而言是一種基礎(chǔ)的安保措施。因此，防御XXE攻擊的措施同樣適用于此類XML實(shí)體擴(kuò)展攻擊。

雖說可以通過上述方式進(jìn)行防御，遠(yuǎn)程實(shí)體擴(kuò)展通過使XML解析器發(fā)出遠(yuǎn)程HTTP請(qǐng)求來獲得被引用實(shí)體的擴(kuò)展值來進(jìn)行攻擊。返回結(jié)果將自行定義其他XML解析器必須另行HTTP請(qǐng)求的外部實(shí)體。如此一來，一些看似并無攻擊性的請(qǐng)求會(huì)迅速脫離控制，并給服務(wù)器的可用資源帶來負(fù)擔(dān)。這種情況下，如果請(qǐng)求自包括一個(gè)遞歸擴(kuò)展攻擊，那最終結(jié)果會(huì)更加糟糕。

]>

    3..2..1...&cascade

上述攻擊手法還有可能更加迂回地進(jìn)行DOS攻擊，比如，遠(yuǎn)程請(qǐng)求被調(diào)整到針對(duì)本地程序或其他任何共享其服務(wù)器資源的程序。這種攻擊方式可能造成自我損傷式的DOS攻擊，其中， XML解析器嘗試解析外部實(shí)體可能會(huì)觸發(fā)無數(shù)針對(duì)本地程序的請(qǐng)求，并由此消耗更多的服務(wù)器資源。該方式因此被用于放大之前討論過的關(guān)于使用XML外部實(shí)體注入式攻擊（XXE）以完成DOS攻擊的攻擊影響。

下列常規(guī)防御措施，是從我們針對(duì)普通XML外部實(shí)體攻擊（XXE）的防御措施繼承而來的。我們應(yīng)當(dāng)拒絕XML中自定義實(shí)體對(duì)本地文件和遠(yuǎn)程HTTP請(qǐng)求的解析，并可使用以下可全局應(yīng)用于所有內(nèi)部使用了libxml2函數(shù)的PHP或XML所書寫擴(kuò)展的函數(shù)進(jìn)行拒絕。

libxml_disable_entity_loader(true);

誠然PHP以不按常理出牌著稱，它并不使用常規(guī)的防御方式。常規(guī)的防御方式在文檔類型聲明中，使用XML的文檔類型定義來完全拒絕通過自定義實(shí)體的定義。PHP也的確為防御功能定義了一個(gè)替代實(shí)體的LIBXML_NOENT常量，以及 DOMDocument::$substituteEntities 公共屬性，但是使用這兩條定義的防御效果不甚明顯。似乎我們只能這樣將就解決問題，而沒有任何更好的解決方案。

雖說沒有更好的方案，libxml2函數(shù)也確實(shí)內(nèi)置了默認(rèn)拒絕遞歸實(shí)體解析。要知道遞歸實(shí)體要是出了問題可是能讓你的錯(cuò)誤日志”咻”地一下跟點(diǎn)亮圣誕樹一樣全面飄紅的。如此看來，好像也沒必要特意針對(duì)遞歸實(shí)體使用一種特殊防御手段，盡管我們是得做點(diǎn)什么來防止萬一libxml2函數(shù)突然陷回解析遞歸實(shí)體的故障里去。

當(dāng)下新型威脅主要來自Generic Entity Expansion 或者Quadratic Blowup Attack的粗暴攻擊方式。此類攻擊方式不需要調(diào)用遠(yuǎn)程或本地系統(tǒng)，也不需要實(shí)體遞歸。事實(shí)上，唯一的防御措施要么是不用XML，要么是清理過濾所有包含文檔類型聲明的XML。除非要求的文檔類型聲明接收于安全的可信源，否則最安全的做法就是不用XML了。比如，我們是由同行驗(yàn)證的HTTPS連接接受的。否則，既然PHP沒給我們提供禁用文檔類型定義的選項(xiàng)，那我們就只能自建邏輯了。假定你能調(diào)用 libxml_disable_entity_loader(TRUE)，那么后續(xù)程序運(yùn)行就是安全的了，因?yàn)閷?shí)體擴(kuò)展這一步已經(jīng)被遞延到被擴(kuò)展影響的節(jié)點(diǎn)值可被再次訪問的時(shí)候了（然而勾選TURE以后永遠(yuǎn)都訪問不到了）。

$dom = new DOMDocument;
$dom->loadXML($xml);
foreach ($dom->childNodes as $child) {
    if ($child->nodeType === XML_DOCUMENT_TYPE_NODE) {
        throw new InvalidArgumentException(
            "Invalid XML: Detected use of illegal DOCTYPE"
        );
    }
}

當(dāng)然啦，在 libxml_disable_entity_loader 被設(shè)定為TRUE的前提下，以上代碼才能正常運(yùn)行，設(shè)定后XML初始加載的時(shí)外部實(shí)體引用就不會(huì)被解析了。除非解析器自己有一套全面的針對(duì)如何進(jìn)行實(shí)體解析的控制選項(xiàng)，否則XML解析器不依賴libxml2函數(shù)進(jìn)行解析時(shí)，恐怕這就是唯一的防御措施了。

如果你想使用SimpleXML函數(shù)，記得用the simplexml_import_dom()函數(shù)來轉(zhuǎn)換核驗(yàn)過的DOMDocument項(xiàng)目。

原文地址：Injection Attacks

OneAPM for PHP 能夠深入到所有 PHP 應(yīng)用內(nèi)部完成應(yīng)用性能管理 能夠深入到所有 PHP 應(yīng)用內(nèi)部完成應(yīng)用性能管理和監(jiān)控，包括代碼級(jí)別性能問題的可見性、性能瓶頸的快速識(shí)別與追溯、真實(shí)用戶體驗(yàn)監(jiān)控、服務(wù)器監(jiān)控和端到端的應(yīng)用性能管理。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客