So finden und beheben Sie XML-Entity-Schwachstellen
Michael Sherman
7. September 2022
0 Min. LesezeitXML ist ein menschenlesbares Textformat, das zum Übertragen und Speichern strukturierter Daten verwendet wird. Tags und Datenstrukturen werden von Benutzern in selbsterklärenden Dokumenten definiert, die von jedem XML-Tool universell geparst werden können. Dadurch erhalten Entwickler einen hochgradig konfigurierbaren Mechanismus zur Datendarstellung.
Aufbauend auf der eingeschränkten Basissyntax von XML kann ein Autor mithilfe einer Document Type Definition (DTD) die Struktur und zulässigen Inhalte der Daten eines Dokuments festlegen. Mit der DTD können Benutzer gültige Dokumentdaten definieren und Daten an einer Stelle beschreiben, um sie im gesamten Dokument wiederzuverwenden. Eine allgemeine Entity wird in der DTD deklariert und anschließend im Dokumentkörper referenziert, indem vor ihrem Namen ein kaufmännisches Und (&) und danach ein Semikolon (;) eingefügt wird.
Sie können eine Entity im Dokument definieren:
Sie können eine Entity aber auch in einer externen Quelle deklarieren, indem Sie auf einen Dateipfad oder eine URL verweisen:
Die Datei person.dtd enthält:
Diese Funktionalität macht es in Kombination mit der einfachen XML-Syntax und der Einheitlichkeit der meisten Parser für Angreifer relativ einfach, einen Angriff namens XML External Entity (XXE)-Injection durchzuführen. In diesem Beitrag sehen wir uns XXE genauer an und untersuchen Möglichkeiten, den Angriff zu verhindern.
Warum XXE ein Sicherheitsrisiko darstellt
XXE-Injection-Angriffe ermöglichen es Angreifern, externe Entity-Deklarationen auszunutzen, um Zugriff auf Dateien oder Infrastruktur auf dem Zielserver oder -netzwerk zu erhalten. Dazu können sensible personenbezogene Daten, Geschäftslogik und Anmeldedaten gehören.
In schwerwiegenden Fällen können Angreifer eine Server-Side Request Forgery begehen. Dadurch können sie sich als Server im Netzwerk ihres Ziels ausgeben und möglicherweise Code aus der Ferne ausführen. So können sie ihre Berechtigungen ausweiten, die Infrastruktur ihres Ziels durchlaufen und andere ungeschützte Komponenten angreifen – oder Angriffe, die scheinbar von ihrem Ziel ausgehen, in nachgelagerte Netzwerke weitertragen.
Daten abrufen
Die häufigste XXE-Injection-Schwachstelle ermöglicht es Angreifern, einen Server dazu zu veranlassen, sensible Daten oder Dateien in einer HTTP-Antwort offenzulegen. Für sich genommen gewährt dies einem Angreifer lediglich Lesezugriff auf Daten, kann aber Informationen preisgeben, die eine Eskalation zu einem folgenschwereren Angriff ermöglichen.
Ein Angreifer kann beispielsweise eine Payload an einen Zielserver senden, die den Server dazu bringt, eine lokale Passwortdatei anzuzeigen:
Die Implementierung eines robusten Datenverschlüsselungsprotokolls verhindert den Datenabruf wirksam, da gespeicherte Daten dadurch unlesbar und unbrauchbar werden – selbst wenn ein Angreifer erfolgreich in den Zielserver eindringt. Wenn Sie symmetrische Algorithmen wie den Advanced Encryption Standard (AES) zum Speichern und Übertragen sensibler XML-basierter Informationen verwenden, legen Sie einen geheimen Sicherheitsschlüssel fest, mit dem Ihre Daten verschlüsselt und entschlüsselt werden.
Darüber hinaus ist es eine wirksame Gegenmaßnahme gegen diese Art von Angriff, die standardmäßige Unterstützung des XML-Parsers für externe Entities zu deaktivieren.
Server-Side Request Forgery
Ein für XXE-Injection anfälliger Server bietet Angreifern die Möglichkeit, sich als Server auszugeben und Anfragen an interne Ressourcen zu senden, die normalerweise von außerhalb des Netzwerks nicht sichtbar sind.
Bei einem Server-Side-Request-Forgery-Angriff (SSRF) schleust ein Angreifer in der Regel eine URL oder Adresse ein, die auf das lokale Dateisystem des anfälligen Servers oder andere zugriffsbeschränkte Ressourcen verweist – insbesondere, wenn Benutzereingaben vom XML-Parser nicht ordnungsgemäß gefiltert werden. So können Angreifer Anmeldedaten erlangen und administrative Berechtigungen im Netzwerk ihres Ziels erhalten:
Gelingt es dem Angreifer, administrative Berechtigungen zu erlangen, kann er sich als Server ausgeben und das Netzwerk seines Ziels auf weitere Schwachstellen untersuchen. Möglicherweise kann er sogar Code aus der Ferne ausführen und weitere Angriffe verbreiten.
Mit einigen Maßnahmen lässt sich die Widerstandsfähigkeit Ihrer Anwendung gegen diese Art von Angriff erheblich verbessern:
Blockieren Sie alle nicht autorisierten eingehenden Benutzeranfragen an interne Ressourcen und vertrauliche Adressen.
Erwägen Sie eine umfassende Sperrliste mit potenziell schädlichen Adressen und URLs, die eine Gefahr für Ihre Webinfrastruktur darstellen könnten.
Setzen Sie intelligente Tools zur statischen Analyse ein (wie Snyk Code), mit denen sich Ihr Code auf Schwachstellen und Sicherheitslücken prüfen lässt.
Remote Code Execution
Ein Angreifer kann XXE-Injection nutzen, um Remote Code Execution (RCE) auf einem Zielserver auszuführen.
Ein Angreifer kann beispielsweise eine PHP-gestützte Website oder Anwendung angreifen, auf der das Expect-Plugin aktiviert ist. Dazu deklariert er eine Entity mit dem Expect-Wrapper, um Befehle aus der Ferne auszuführen:
Der Befehl ifconfig gibt in diesem Beispiel die Netzwerkkonfiguration des Servers zurück, wenn der XML-Parser die Entity xxe auswertet.
RCE lässt sich verhindern, indem Sie Protokoll-Wrapper wie die PHP-Erweiterung Expect auf Ihren Websites oder in Ihren Web-Apps gezielt deaktivieren.
Doch selbst wenn der Server keine direkte Antwort zurückgibt, kann ein Angreifer stattdessen blinde XXE-Methoden einsetzen.
Blinde XXE-Angriffe
In manchen Fällen verhindern XML-Parser Entity-Deklarationen im Textkörper von XML-Dokumenten. Angreifer können diese Einschränkung mithilfe von Parameter-Entities umgehen, die nur in der DTD oder als Wert einer anderen Entity deklariert werden. Eine Parameter-Entity wird deklariert, indem ihrem Namen ein Prozentzeichen und ein Leerzeichen (%) vorangestellt werden. Referenziert wird sie, indem vor ihrem Namen ein Prozentzeichen (%) und danach ein Semikolon (;) eingefügt wird.
Bei diesem Code versucht der Zielserver, die HTTP-Anfrage an die URL des Angreiferservers zu senden. Dadurch kann der Angreifer mit diesem blinden XXE-Angriff eine DNS-Abfrage des Zielservers durchführen.
Offenlegung von Informationen über Fehlermeldungen
Unser Server ist anfällig für blinde XXE-Injection-Methoden, wenn ein Angreifer wertvolle Daten aus den Fehlermeldungen abrufen kann, die unser Server ausgibt.
Diese Payload zwingt unseren Server beispielsweise dazu, die Datei /etc/pâsswd in seiner Fehlermeldung offenzulegen:
Diese Payload definiert drei Parameter-Entities: badfile, die mit dem Inhalt der Datei /etc/pâsswd gefüllt wird, wrapper, die die dynamische Deklaration einer neuen Parameter-Entity namens induce enthält, und die Entity induce, die eine Abfrage eines Pfads auslöst, bei dem eine Fehlermeldung ausgegeben wird.
Um die Entity wrapper zu deklarieren, deklariert der Angreifer dynamisch die Entity induce, die einen gültigen, aber nicht vorhandenen Pfad enthält, in den der Wert des Parameters badfile eingebettet ist. Wird anschließend auf die Entity wrapper verwiesen, wird die dynamische Deklaration der Entity induce ausgelöst.
Wenn der Parser schließlich auf die Entity induce trifft, gibt er eine Fehlermeldung aus, die den Benutzer darüber informiert, dass die Datei mit dem Namen des Werts von badfile im Pfad nosuchfileexists nicht existiert. Da badfile den Inhalt von etc/pâsswd enthält, werden diese Informationen dem Angreifer angezeigt.
Ein robustes Fehlerbehandlungsprotokoll kann die Anfälligkeit unserer Anwendung für die Offenlegung von Informationen über Fehlermeldungen verringern. Dazu kann gehören, Länge und Umfang der Fehlermeldungen zu begrenzen, die der Server an den Client sendet. Mit einem benutzerdefinierten Nachrichtentext und HTTP-Statuscode lassen sich ausführliche, automatisch generierte Fehlermeldungen vermeiden, da sie Angreifern im Wesentlichen kostenlose Informationen zur Erkundung liefern.
Wir müssen Fehlermeldungen für erwartete Szenarien klar definieren, beispielsweise für die Ausnahme FileNotFound unseres Beispielservers. Außerdem müssen wir geeignete Fehlermeldungen für Sonderfälle festlegen. Dazu müssen wir unseren Code in der Regel testen.
Exfiltration über einen Out-of-Band-Kanal
Bei einem Out-of-Band-Angriff werden Daten über einen anderen Kanal exfiltriert als den, über den der Angriff gesendet wurde. Bei dieser Angriffsart wird der Zielserver in der Regel angewiesen, eine Anfrage an eine Adresse zu senden, auf der der Angreifer eine schädliche externe DTD hostet.
Zunächst muss der Angreifer eine manipulierte Payload mit dem Inhalt einer schädlichen DTD senden, zum Beispiel:
Die Datei corrupted.dtd auf dem Angreiferserver enthält:
Wird die Entity revealinfo ausgeführt, wird eine HTTP-Anfrage an den Angreiferserver gesendet. Der Wert von badfile ist dabei in der Anfragezeichenfolge enthalten.
Wird auf die Entity deval verwiesen, wird die dynamische Deklaration der Entity revealinfo ausgelöst.
Weitere Angriffsvektoren
Weitere häufige Angriffsvektoren für XXE-Angriffe sind:
Datei-Uploads, beispielsweise von
.config-DateienTexteingabefelder, insbesondere HTML-Felder wie
textundtextarea, für die möglicherweise nur eingeschränkte Regeln zur Eingabevalidierung geltenXML-basierte Technologien wie RSS-Feeds und APIs
XML-basierte Dateien, insbesondere gängige Formate wie SVG-Bilder
Ein Angreifer kann beispielsweise eine SVG-Datei hochladen, die einen Link zu einem schädlichen Dokument enthält, um einen XML-Bombenangriff auszuführen:
Die Payload könnte etwa so aussehen:
Der Parser sieht mehrere Entity-Deklarationen in der DTD, wertet sie aber nicht sofort aus. Anschließend liest er das Dokument und trifft auf das Element bin, das er durch Erweiterung der Entity a4 aufruft. Dazu muss er jedoch die zehn enthaltenen Instanzen der Entity a3 erweitern, wofür wiederum die darin enthaltenen Entities a2 erweitert werden müssen – bis hinunter zu a0.
Die endgültige erweiterte Größe des Elements bin umfasst die rekursive Erweiterung aller Elemente in der Entity a4. Bei einer Payload mit zehn oder mehr Ebenen verschachtelter Entities kann die resultierende Datei Hunderte von Gigabyte groß werden. Dies führt beim Server, der die SVG-Datei zu parsen versucht, meist zu einem Speicherfehler – und für unsere Benutzer zu einem Denial-of-Service-Angriff.
Automatische Grenzwerte für den Speicher- oder sonstigen Ressourcenverbrauch bei der Anfrageverarbeitung reichen aus, um viele Arten von DoS-Angriffen zu verhindern, da diese in der Regel die Kapazität eines Servers überlasten sollen.
Allgemeingültige Sicherheitspraktiken
Unterstützung für externe Entities deaktivieren
Das Zulassen externer Entities und benutzerdefinierter DTDs zu unterbinden, reicht oft aus, um viele Arten von XXE-Injection-Angriffen zu verhindern. Die meisten Tools bieten dafür Einzeiler.
Eine Web Application Firewall (WAF) verwenden
Web Application Firewalls (WAFs) sind ein wirksames Mittel gegen XXE-Angriffe. Sie prüfen den HTTP-Datenverkehr auf potenziell schädliche Inhalte und wenden Filterregeln an, um unsere Webanwendungen zu schützen.
Zero-Trust-Sicherheit implementieren
Das Vertrauensverhältnis zwischen Ihren Webanwendungen und anderen externen Diensten oder Diensten von Drittanbietern (wie Message Brokern und Plattformen zur Benutzerauthentifizierung) kann für einen SSRF-Angriff auf Ihre Serverinfrastruktur ausgenutzt werden. Außerdem sollten Dienste innerhalb Ihres Netzwerks nur auf die Ressourcen zugreifen dürfen, die sie für ihre ordnungsgemäße Funktion benötigen.
Wir sollten Logs und sensible Daten angemessen voneinander isolieren und zuverlässige Prozesse einführen, um die Zugriffsrechte aller Benutzer – sowohl menschlicher als auch programmatischer – regelmäßig zu überprüfen. Das erleichtert auch die langfristige Verwaltung der Sicherheitswartung.
XXE-Schwachstellen regelmäßig automatisiert scannen und testen
Automatische XXE-Schwachstellenscans können dabei helfen, Schwachstellen in Ihrer Infrastruktur zu erkennen und zu beheben, bevor ein Angreifer sie ausnutzt. Ein umfassendes und intelligentes Erkennungssystem sollte außerdem Empfehlungen dazu geben, wie sich das System weiter absichern lässt.
Sicherheitspatches stets auf dem neuesten Stand halten
Es ist wichtig, dass unsere Systeme stets aktuelle Patches von vertrauenswürdigen Sicherheitsanbietern erhalten. Dazu können Updates für Sicherheitstreiber und Patches zum Schutz vor DoS-Angriffen gehören. Aktuelle Informationen zu Open-Source-Schwachstellen finden Sie bei Snyk Open Source. Das Produkt wird von der umfassenden, präzisen und aktuellen Snyk Vulnerability Database unterstützt.
Risiken mit den Schutzfunktionen von Snyk reduzieren
Bibliotheken von Drittanbietern können manchmal ausgenutzt werden und dadurch Ihre Anwendung Angriffen aussetzen. Um den Schutz Ihrer Anwendung weiter zu stärken, empfehlen wir Ihnen, jede in Ihre Anwendung integrierte Bibliothek eines Drittanbieters mit Snyk OSS zu scannen.
Mit den Funktionen von Snyk Code können Sie außerdem potenzielle Sicherheitslücken erkennen und beheben, bevor sie ausgenutzt werden.
Abschließende Gedanken zur XML-Sicherheit
XML ist ein vielseitiges und leistungsstarkes Tool für den Datentransport – umso mehr, als es uns ermöglicht, verknüpfte externe Ressourcen dynamisch zu verwenden. Diese Eigenschaften machen XML jedoch auch zu einem beliebten Werkzeug für böswillige Akteure. Um die damit verbundenen Risiken angemessen zu verhindern und einzudämmen, ist es entscheidend, die potenziellen Schwachstellen zu verstehen, die XML mit sich bringen kann.
Unzureichend bereinigte Benutzereingaben, zu ausführliche Fehlerbehandlung und schwach konfigurierte Zugriffsrechte ermöglichen es Angreifern, Systeme mithilfe von Angriffen durch XML External Entity (XXE)-Injection zu kompromittieren. Diese Schwachstellen lassen sich wirksam beheben, indem Sie Benutzereingaben und Uploads validieren und filtern und in den meisten Fällen Funktionen wie die Verarbeitung externer DTDs oder PHP-Protokoll-Wrapper einfach entfernen.
Fehlermeldungen sollten dem Benutzer möglichst wenige Informationen mitteilen. Wenn ein Benutzer beispielsweise bei einem Anmeldeversuch scheitert, muss ihm nicht mitgeteilt werden, ob das Passwort oder der Benutzername falsch war.
Sie können außerdem WAFs und DoS-Schutzmaßnahmen implementieren oder einen Dienstanbieter nutzen, der diese Funktionen anbietet. Und sollte ein Angreifer die Sicherheitsmaßnahmen überwinden, sollte er nur auf verschlüsselte Daten und ein Netzwerk aus Zero-Trust-Diensten treffen.
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.
