Skip to main content

XXE-Sicherheitslücken in Nokogiri beheben

Artikel von
Headshot of Tim Kadlec

Tim Kadlec

14. Februar 2017

0 Min. Lesezeit

Kürzlich haben wir zwei schwerwiegende Sicherheitslücken durch XML External Entities (XXE) in der Nokogiri-Bibliothek in unsere Schwachstellendatenbank aufgenommen. In diesem Beitrag erklären wir, wie die Sicherheitslücken funktionieren und wie Sie den Exploit in Ihrer Anwendung beheben.

Nokogiri ist eine sehr beliebte Bibliothek zum Parsen und Extrahieren von Daten aus XML-, SAX-, Reader- oder HTML-Dokumenten. Nokogiri nutzt Bibliotheken wie libxml2 und libxslt, damit sich diese Dokumente einfach mit XPath oder sogar CSS3-Selektoren parsen lassen.

XML-External-Entity-Angriffe verstehen

Um einen String als XML zu parsen, übergeben Sie ihn zunächst mit der XML-Methode an Nokogiri:

    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>

Der XML-Standard unterstützt sogenannte externe Entitäten, die mithilfe eines Links definiert werden können. Beim Parsen eines XML-Dokuments kann der Parser eine Anfrage an diese Links senden und den Inhalt der angegebenen URI in das XML-Dokument einfügen. Zum Beispiel könnten wir eine externe Entität unter http://0.0.0.0:8000/evil.dtd einbinden:

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

Ist ein XML-Parser so konfiguriert, dass er externe Entitäten einbindet, können Angreifer durch das Einschleusen einer bösartigen Entität einen XML-External-Entity-Angriff ausführen. Die Folgen können gravierend sein: XXE-Angriffe können zu Denial-of-Service, Port-Scans und der Offenlegung vertraulicher Informationen führen.

Am sichersten verhindern Sie einen XXE-Angriff, indem Sie Ihren XML-Parser so konfigurieren, dass er externe DTDs überhaupt nicht einbindet. Leider kann die zugrunde liegende Bibliothek, die Nokogiri zum Parsen von XML verwendet (libxml2), Anwendungen für diesen Angriff anfällig machen.

Die Sicherheitslücke

In Nokogiri-Versionen vor 1.5.4 sendet Nokogiri beim Parsen eines Strings mit einer definierten XXE standardmäßig eine Anfrage für jede definierte XXE. Wenn wir also versuchen, den zuvor erwähnten String zu parsen, wird eine Anfrage an http://0.0.0.0:8080 für evil.dtd gesendet.

Nokogiri-Versionen nach 1.5.4 enthalten einige Schutzmaßnahmen, um das Risiko der Sicherheitslücke zu begrenzen. Nokogiri bietet zwei Optionen, die für diesen Angriff relevant sind. Die erste ist die Option DTDLOAD. Sie legt fest, ob Nokogiri beim Parsen von XML gefundene DTDs laden soll.

Die andere Option ist NONET. Ist die Option NONET aktiviert, können keine unbekannten Dokumente aus dem Netzwerk geladen werden.

Bei Nokogiri-Versionen nach 1.5.4 ist die Option DTDLOAD in der Standardkonfiguration auf false und die Option NONET auf true gesetzt. Mit anderen Worten: Nokogiri versucht standardmäßig nicht, definierte DTDs zu laden, und lädt auch keine Dokumente über das Netzwerk – die Sicherheitslücke kann also nicht ausgenutzt werden.

Wenn ein Benutzer jedoch die Option DTDLOAD auf true und zugleich die Option NONET auf false setzt, können Angreifer die Sicherheitslücke ausnutzen.

So beheben Sie die Sicherheitslücke

Die Sicherheitsprobleme wurden vom Snyk-Sicherheitsteam entdeckt und am 11. Januar an Nokogiri gemeldet. Das Nokogiri-Team prüfte das Problem umgehend, doch leider sind dem Team in diesem Fall die Hände gebunden. Das Problem liegt nicht in Nokogiri selbst, sondern in der zugrunde liegenden Bibliothek libxml2. Nokogiri wartet darauf, dass dort ein Patch bereitgestellt wird, damit das Update übernommen werden kann.

Falls Sie feststellen, dass Ihr Projekt von dieser Sicherheitslücke betroffen ist, können Sie einige Schritte unternehmen, um das Problem bis dahin zu entschärfen.

Vergewissern Sie sich zunächst, dass Sie Nokogiri in Version 1.5.4 oder höher verwenden. Wie bereits erwähnt, sind Versionen vor 1.5.4 standardmäßig anfällig.

Nachdem Sie Nokigiri aktualisiert haben, prüfen Sie noch einmal Ihre Einstellungen. Stellen Sie sicher, dass DTDLOAD nicht auf true und NONET nicht auf false. gesetzt ist. Die Standardeinstellungen sollten sicher sein. Wenn Sie diese Werte jedoch geändert haben, sind Sie derzeit anfällig. Sie können auch nur eine der beiden Optionen ändern – die Sicherheitslücke besteht nur, wenn beide entsprechend konfiguriert sind.

Mit diesen Schritten schützen Sie sich jetzt vor der Sicherheitslücke. Wenn Sie Ihr Projekt überwachen, benachrichtigen wir Sie, sobald eine Fehlerbehebung verfügbar ist.

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Ihr Schwachstellen-Backlog ist keine technische Schuld mehr, sondern eine Angriffsfläche

Ein wachsender Schwachstellen-Backlog ist mehr als eine technische Altlast: Er ist eine Angriffsfläche. Erfahren Sie, warum veraltete Risikoeinschätzungen, automatisierte Angreifer und verkettete Findings einen neuen Ansatz erfordern.