Java und XML – eine riskante Kombination

XML ist, das dürfte den meisten Lesern bekannt sein, ein Meta-Dateiformat, in dem sich Daten strukturiert ablegen lassen. XML stammt aus einer Zeit, in der viele noch glaubten, dass IT-Technologie vor allem dann gut ist, wenn sie möglichst komplex ist und viele Features hat.

Wer den XML-Standard streng nach Spezifikation implementiert, endet fast automatisch bei Software, die gravierende Sicherheitslücken hat. Die meisten Sicherheitsprobleme von XML hängen mit der Verarbeitung sogenannter Entities zusammen.

Durch einen Entity kann man im Header eines Dokuments eine kurze Zeichenfolge definieren, die durch eine andere Zeichenfolge ersetzt wird. Ein normaler Entity fängt dabei immer mit einem &-Zeichen an und endet mit einem Strichpunkt (;).

Entities lassen sich auch verschachteln, und damit besteht die Möglichkeit, Dokumente zu erzeugen, die bei der Verarbeitung Unmengen an Rechenzeit und Speicher benötigen. Anwendungen benötigen dann entweder sehr lange zur Verarbeitung oder stürzen ab. Diese Schwachstelle ist als Billion-Laughs-Angriff bekannt.

Solche Billion-Laughs-Angriffe führen "nur" dazu, dass eine Anwendung potenziell abstürzt oder sehr viel Rechenzeit benötigt, daher sind die Auswirkungen begrenzt. Erwähnenswert ist, dass es sich hierbei nicht um einen einzelnen Angriff handelt, sondern um eine ganze Klasse von verwandten Problemen. Immer wieder werden auch in viel verwendeten XML-Parsern neue derartige Probleme entdeckt. Aktuell gibt es etwa zwei bislang nicht gefixte Sicherheitslücken in Expat , eine der am häufigsten verwendeten XML-Bibliotheken.

XXE-Angriffe – schon lange bekannt

Weit gravierender als diese Denial-of-Service-Probleme sind XXE-Sicherheitslücken (Xml eXternal Entity Injection). Dabei nutzt man als Angreifer aus, dass Entities auch Dateien auslesen können. Das lässt sich am besten mit einem einfachen Beispiel zeigen:

        
<!DOCTYPE xxe [
<!ENTITY e SYSTEM "file:///etc/passwd">
]>
<x>&e;</x>

Hier wird ein Entity &e; definiert, der den Inhalt der Datei /etc/passwd ausgibt. Anschließend wird dieser Entity im XML-Dokument verwendet. In Fällen, in denen man einer auf einem fremden System laufenden Software eine XML-Datei geben und die verarbeitete Ausgabe sehen kann, kann man hiermit Dateien auslesen. In Bezug auf Rechnungen wäre ein Beispiel etwa ein Onlineservice, bei dem man eine Rechnung hochladen und anzeigen kann.

Auch in Situationen, in denen eine XML-Datei verarbeitet wird, aber der Angreifer die Ausgabe nicht zu Gesicht bekommt, ist eine Exfiltrierung von Dateien möglich. Hierfür ist ein sogenannter Blind-XXE-Angriff nötig, der etwas komplexer ist und hier nicht im Detail erklärt werden soll. Die Kernidee ist dabei, eine URL zu konstruieren, die auf einen vom Angreifer kontrollierten Hostnamen verweist und an die der Inhalt einer Datei angehängt wird. Blind-XXE-Angriffe haben einige Einschränkungen, so lassen sich etwa bei vielen XML-Parsern keine URLs aufrufen, die Sonderzeichen oder Newlines enthalten.

XXE-Angriffe sind keine Neuheit, und viele Softwareprojekte haben inzwischen darauf reagiert und sind standardmäßig nicht mehr verwundbar. So gab es etwa bereits 2013 ein entsprechendes Update für die Standardbibliothek in Python , das den Aufruf von lokalen und externen URLs standardmäßig deaktiviert. Bei .NET änderte man die Defaults 2016 . Die LibXML2-Bibliothek löst seit 2013 standardmäßig keine Entities auf , in Expat muss man zur Nutzung von URLs einen speziellen Handler konfigurieren .

All das bietet keine 100-prozentige Sicherheit, doch zumindest in der Standardkonfiguration sind viele XML-Parser nicht mehr für XXE verwundbar. Man muss aktiv potenziell gefährliche Features aktivieren, um verwundbar zu werden.

Doch es gibt auch im Jahr 2025 noch Bibliotheken und APIs, die standardmäßig keinerlei Schutz gegen XXE-Angriffe bieten. Das gilt etwa für die Programmiersprache Java und die in der Standard-Bibliothek verfügbare XML-Funktionalität.