摘要:雖說可以通過上述方式進(jìn)行防御,遠(yuǎn)程實體擴(kuò)展通過使解析器發(fā)出遠(yuǎn)程請求來獲得被引用實體的擴(kuò)展值來進(jìn)行攻擊。返回結(jié)果將自行定義其他解析器必須另行請求的外部實體。
XMl Entity Expansion(攻擊)某種程度上類似于 XML Entity Expansion,但是它主要試圖通過消耗目標(biāo)程序的服務(wù)器環(huán)境來進(jìn)行DOS攻擊的。這種攻擊基于XML Entity Expansion實現(xiàn),通過在XML的DOCTYPE中創(chuàng)建自定義實體的定義實現(xiàn),比如,這種定義可以在內(nèi)存中生成一個比XML的原始允許大小大出很多的XML結(jié)構(gòu),來使這種攻擊得以耗盡網(wǎng)絡(luò)服務(wù)器正常有效運行的必需內(nèi)存資源。這種攻擊方式同樣適用于HTML5的XML序列化功能模塊,該模塊當(dāng)前還不能被libxml2擴(kuò)展包識別為HTML。
XML Entity Expansion舉例要擴(kuò)展XML自定義實體以達(dá)到預(yù)期的耗盡服務(wù)器資源效果有好幾種方式。
Generic Entity Expansion 通用實體擴(kuò)展攻擊通用實體擴(kuò)展攻擊同樣被稱為“Quadratic Blowup Attack”,使用這種方式時,自定義實體被定義為一個極長的字符串。當(dāng)文件中大量使用這個實體時,該實體在每次調(diào)用時都會進(jìn)行擴(kuò)展,生成一個大幅超出原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;...
通過平衡自定義實體字符串大小和文檔主體內(nèi)使用實體數(shù)量,可以創(chuàng)建一個擴(kuò)展至占用服務(wù)器可預(yù)測RAM空間大小的XML文檔或字符串。通過這樣重復(fù)請求來占用服務(wù)器RAM,就可以發(fā)動一次成功的拒絕服務(wù)攻擊。該方式的缺陷是,由于產(chǎn)生內(nèi)存消耗效果是基于簡單數(shù)乘的,因此初始XML文檔或字符串本身需要足夠大。
遞歸實體擴(kuò)展攻擊通用實體擴(kuò)展攻擊需要足夠大的XML輸入數(shù)據(jù)量,而遞歸實體擴(kuò)展攻擊的平均輸入字節(jié)能產(chǎn)生更強力的攻擊效果。這種攻擊方式依賴于XML解析器來解析,從而完成小實體集的指數(shù)級增長。通過這種指數(shù)爆炸性增長方式,一個比通用實體擴(kuò)展攻擊使用小得多的輸入數(shù)據(jù)量實際可增長得極大。因此這種方式被稱為“XML Bomb”或是“Billion Laughs Attack”也是十分恰切的。
]>Explode in 3...2...1...&boom;
XML Bomb攻擊并不需要可能會被程序限制的大量XML數(shù)據(jù)輸入。實體集像這樣指數(shù)倍增長,最終形成的擴(kuò)展后文本大小是初始 &x0實體值的2的100次方倍。這著實是一個龐大且毀滅性超強的炸彈!
遠(yuǎn)程實體擴(kuò)展攻擊常規(guī)和遞歸實體擴(kuò)展攻擊都依賴于XML文檔類型定義中定義在本地的實體,但是攻擊者同樣可以進(jìn)行外部實體定義。這很顯然需要XML解析器能夠像我們之前在描述XML外部實體注入式攻擊(XXE)時遇到的那樣,發(fā)起遠(yuǎn)程HTTP請求。而拒絕這種請求對你的XML解析器而言是一種基礎(chǔ)的安保措施。因此,防御XXE攻擊的措施同樣適用于此類XML實體擴(kuò)展攻擊。
雖說可以通過上述方式進(jìn)行防御,遠(yuǎn)程實體擴(kuò)展通過使XML解析器發(fā)出遠(yuǎn)程HTTP請求來獲得被引用實體的擴(kuò)展值來進(jìn)行攻擊。返回結(jié)果將自行定義其他XML解析器必須另行HTTP請求的外部實體。如此一來,一些看似并無攻擊性的請求會迅速脫離控制,并給服務(wù)器的可用資源帶來負(fù)擔(dān)。這種情況下,如果請求自包括一個遞歸擴(kuò)展攻擊,那最終結(jié)果會更加糟糕。
]>3..2..1...&cascade
上述攻擊手法還有可能更加迂回地進(jìn)行DOS攻擊,比如,遠(yuǎn)程請求被調(diào)整到針對本地程序或其他任何共享其服務(wù)器資源的程序。這種攻擊方式可能造成自我損傷式的DOS攻擊,其中, XML解析器嘗試解析外部實體可能會觸發(fā)無數(shù)針對本地程序的請求,并由此消耗更多的服務(wù)器資源。該方式因此被用于放大之前討論過的關(guān)于使用XML外部實體注入式攻擊(XXE)以完成DOS攻擊的攻擊影響。
針對XML實體擴(kuò)展攻擊的防御措施下列常規(guī)防御措施,是從我們針對普通XML外部實體攻擊(XXE)的防御措施繼承而來的。我們應(yīng)當(dāng)拒絕XML中自定義實體對本地文件和遠(yuǎn)程HTTP請求的解析,并可使用以下可全局應(yīng)用于所有內(nèi)部使用了libxml2函數(shù)的PHP或XML所書寫擴(kuò)展的函數(shù)進(jìn)行拒絕。
libxml_disable_entity_loader(true);
誠然PHP以不按常理出牌著稱,它并不使用常規(guī)的防御方式。常規(guī)的防御方式在文檔類型聲明中,使用XML的文檔類型定義來完全拒絕通過自定義實體的定義。PHP也的確為防御功能定義了一個替代實體的LIBXML_NOENT常量,以及 DOMDocument::$substituteEntities 公共屬性,但是使用這兩條定義的防御效果不甚明顯。似乎我們只能這樣將就解決問題,而沒有任何更好的解決方案。
雖說沒有更好的方案,libxml2函數(shù)也確實內(nèi)置了默認(rèn)拒絕遞歸實體解析。要知道遞歸實體要是出了問題可是能讓你的錯誤日志”咻”地一下跟點亮圣誕樹一樣全面飄紅的。如此看來,好像也沒必要特意針對遞歸實體使用一種特殊防御手段,盡管我們是得做點什么來防止萬一libxml2函數(shù)突然陷回解析遞歸實體的故障里去。
當(dāng)下新型威脅主要來自Generic Entity Expansion 或者Quadratic Blowup Attack的粗暴攻擊方式。此類攻擊方式不需要調(diào)用遠(yuǎn)程或本地系統(tǒng),也不需要實體遞歸。事實上,唯一的防御措施要么是不用XML,要么是清理過濾所有包含文檔類型聲明的XML。除非要求的文檔類型聲明接收于安全的可信源,否則最安全的做法就是不用XML了。比如,我們是由同行驗證的HTTPS連接接受的。否則,既然PHP沒給我們提供禁用文檔類型定義的選項,那我們就只能自建邏輯了。假定你能調(diào)用 libxml_disable_entity_loader(TRUE),那么后續(xù)程序運行就是安全的了,因為實體擴(kuò)展這一步已經(jīng)被遞延到被擴(kuò)展影響的節(jié)點值可被再次訪問的時候了(然而勾選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的前提下,以上代碼才能正常運行,設(shè)定后XML初始加載的時外部實體引用就不會被解析了。除非解析器自己有一套全面的針對如何進(jìn)行實體解析的控制選項,否則XML解析器不依賴libxml2函數(shù)進(jìn)行解析時,恐怕這就是唯一的防御措施了。
如果你想使用SimpleXML函數(shù),記得用the simplexml_import_dom()函數(shù)來轉(zhuǎn)換核驗過的DOMDocument項目。
原文地址:Injection Attacks
OneAPM for PHP 能夠深入到所有 PHP 應(yīng)用內(nèi)部完成應(yīng)用性能管理 能夠深入到所有 PHP 應(yīng)用內(nèi)部完成應(yīng)用性能管理和監(jiān)控,包括代碼級別性能問題的可見性、性能瓶頸的快速識別與追溯、真實用戶體驗監(jiān)控、服務(wù)器監(jiān)控和端到端的應(yīng)用性能管理。想閱讀更多技術(shù)文章,請訪問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/110338.html
摘要:它受眾廣,同時常用的解析器,例如,允許對進(jìn)行一些默認(rèn)處理。外部實體注入攻擊面對外部實體攻擊的脆弱點在于,解析器的庫往往都支持自定義的實體引用。 注入攻擊 XML注入 雖然JSON的出現(xiàn)實現(xiàn)了服務(wù)器與客戶端之間的輕量級數(shù)據(jù)交流,但是,作為另一種流行的可行方案,許多web服務(wù)API同時還是繼續(xù)支持XML。另外,除了web服務(wù)之外,XML也是許多使用XML schemas 實行數(shù)據(jù)交換的協(xié)議...
摘要:在考慮安全性時,你需要考慮如何避免被濫用,也不例外,即使在標(biāo)準(zhǔn)庫中,也存在用于編寫應(yīng)用的不良實踐。修復(fù)使用替換標(biāo)準(zhǔn)庫模塊,它增加了針對這些類型攻擊的安全防護(hù)。但這卻是中最大的安全漏洞之一。 簡評:編寫安全代碼很困難,當(dāng)你學(xué)習(xí)一個編程語言、模塊或框架時,你會學(xué)習(xí)其使用方法。 在考慮安全性時,你需要考慮如何避免被濫用,Python也不例外,即使在標(biāo)準(zhǔn)庫中,也存在用于編寫應(yīng)用的不良實踐。然而...
摘要:應(yīng)用常見安全漏洞一覽注入注入就是通過給應(yīng)用接口傳入一些特殊字符,達(dá)到欺騙服務(wù)器執(zhí)行惡意的命令。此外,適當(dāng)?shù)臋?quán)限控制不曝露必要的安全信息和日志也有助于預(yù)防注入漏洞。 web 應(yīng)用常見安全漏洞一覽 1. SQL 注入 SQL 注入就是通過給 web 應(yīng)用接口傳入一些特殊字符,達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令。 SQL 注入漏洞屬于后端的范疇,但前端也可做體驗上的優(yōu)化。 原因 當(dāng)使用外...
摘要:應(yīng)用常見安全漏洞一覽注入注入就是通過給應(yīng)用接口傳入一些特殊字符,達(dá)到欺騙服務(wù)器執(zhí)行惡意的命令。此外,適當(dāng)?shù)臋?quán)限控制不曝露必要的安全信息和日志也有助于預(yù)防注入漏洞。 web 應(yīng)用常見安全漏洞一覽 1. SQL 注入 SQL 注入就是通過給 web 應(yīng)用接口傳入一些特殊字符,達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令。 SQL 注入漏洞屬于后端的范疇,但前端也可做體驗上的優(yōu)化。 原因 當(dāng)使用外...
閱讀 659·2023-04-25 15:49
閱讀 3115·2021-09-22 15:13
閱讀 1251·2021-09-07 10:13
閱讀 3477·2019-08-29 18:34
閱讀 2559·2019-08-29 15:22
閱讀 510·2019-08-27 10:52
閱讀 686·2019-08-26 18:27
閱讀 3021·2019-08-26 13:44