XSLT 2.0 führt zur Nutzung einer unsicheren Bibliothek
Hier haben wir bereits eine gefährliche Mischung. Java wird sowohl in der öffentlichen Verwaltung, als auch im Bereich von Enterprise- und Business-Software sehr häufig verwendet. Wir haben es mit einem inhärent unsicheren Datenformat zu tun, das häufig mit einer Programmiersprache verarbeitet wird, die standardmäßig verwundbar ist. Doch bei den elektronischen Rechnungen kommt noch etwas hinzu.
Von der EU werden Validierungsartefakte bereitgestellt(öffnet im neuen Fenster) , mit denen man prüfen kann, ob sich eine Rechnung an die Vorgaben von EN 16931 hält. Das ist natürlich erst einmal praktisch, es bietet eine einfache Möglichkeit für Software, Rechnungen, die sich nicht an den Standard halten, zu erkennen. Doch diese Validierungsartefakte sorgen indirekt für noch mehr Sicherheitsrisiken.
Die Validierungsartefakte sind in einer Sprache namens Schematron geschrieben und werden anschließend in XSLT-Dateien übersetzt. Sie nutzen die XSLT-Spezifikation in Version 2.0.
Von XSLT gibt es drei Versionen (1.0, 2.0, 3.0), von den meisten Implementierungen wird jedoch nur XSLT 1.0 unterstützt. Für die späteren XSLT-Versionen gibt es nur eine frei verfügbare Implementierung, eine in Java geschriebene Bibliothek namens Saxon. Für andere Programmiersprachen (PHP, Python, C) existieren Bindings.
Saxon ist nun ebenfalls standardmäßig für XXE-Sicherheitslücken verwundbar. Gegenüber dem Autor dieses Textes haben dessen Entwickler klargemacht, dass sich daran auch nichts ändern wird.
XSLT 2.0 ist bereits seit 2007 eine Empfehlung des W3C. Die gesamte Konstellation – ein "Standard", der von den meisten Implementierungen nicht unterstützt wird, nur eine frei verfügbare Implementierung, die nicht besonders sicher ist – kann man problematisch finden. Der Autor dieses Textes hat auch das W3C auf diese Problematik aufmerksam gemacht(öffnet im neuen Fenster) , aber dort scheint man darin kein Problem zu sehen.
Für die elektronischen Rechnungen der EU bedeutet das ein zusätzliches Risiko. Wer Software schreibt, die Rechnungen nach EN 16931 verarbeitet, und sie mit den Validierungsartefakten prüfen möchte, dürfte dafür in den allermeisten Fällen Saxon verwenden. Wer Saxon verwendet und nichts von den inhärenten Sicherheitsproblemen weiß, ist für XXE-Angriffe verwundbar.
Wir haben also ein Konglomerat an Rechnungsstandards, die auf XML basieren. Ein Großteil der Software, die diese Rechnungen verarbeitet, ist entweder in Java geschrieben oder nutzt Saxon – oder beides. Sowohl Java als auch Saxon sind standardmäßig für XXE-Sicherheitslücken verwundbar.
13 Sicherheitslücken während Recherche gefunden
Das Resultat ist erwartbar: viel Software mit Sicherheitslücken. Im Zuge der Recherche hat der Autor dieses Textes insgesamt 13 XXE-Sicherheitslücken an die Entwickler verschiedener Tools gemeldet.
Dazu sollte man erwähnen, dass es in dem Bereich viel Software gibt, die wir nicht testen konnten. Viele Softwareprodukte, die mit elektronischen Rechnungen arbeiten, sind kommerzielle Lösungen ohne frei verfügbare Testinstallationen oder Accounts. Getestet haben wir primär kostenlos verfügbare Tools und Onlineservices, mit denen Rechnungen verarbeitet, geprüft oder visualisiert werden können.
Um auch anderen Menschen zu ermöglichen, entsprechende Software auf Sicherheitslücken zu prüfen, steht eine vom Autor dieses Textes erstellte Testsuite bereit(öffnet im neuen Fenster) .
Viel zu komplexes und enorm anfälliges Konstrukt
Fassen wir also zusammen: Maschinenlesbare Rechnungen sind im Grunde eine sinnvolle Sache. Doch verschiedene unglückliche Entscheidungen von Standardisierungsgremien und der EU haben hier ein Konstrukt geschaffen, das viel zu komplex und enorm anfällig für Sicherheitsprobleme ist.
Was kann man daraus lernen? Zunächst einmal sollten natürlich bestehende Sicherheitsprobleme erkannt und behoben werden. All diejenigen, die Software entwickeln, die elektronische Rechnungen verarbeitet, sollten sich mit der Problematik von XXE-Sicherheitslücken vertraut machen und ihre Produkte auf Verwundbarkeit prüfen.
Wünschenswert wäre, dass der Wildwuchs an Standards, Syntaxen und Profilen bei den EU-Rechnungen eingedämmt wird. Klar, Rechnungen sind inhärent komplex, aber das heißt nicht, dass man ohne Not noch unnötige technische Komplexität obendraufpacken muss.
Für neue Standards und Dokumentenformate XML nicht mehr nutzen
Perspektivisch sollte man daraus lernen. Zumindest für neue Standards und Dokumentenformate sollte man XML nicht mehr nutzen. Ein Format, das inhärent unsicher ist, ist ungeeignet für Dateien, die zwischen zahlreichen Akteuren ausgetauscht und dabei von unterschiedlichster Software verarbeitet werden. Doch auch Softwarehersteller tragen hier eine Verantwortung. Dass manche Software wie Saxon und Oracles Java standardmäßig unsichere XML-Parser ausliefern, ist absolut unverantwortlich.
Weniger unsichere Datenformate wie JSON – nicht perfekt(öffnet im neuen Fenster) , aber definitiv weniger riskant als XML – würden viele Sicherheitsrisiken von vornherein ausschließen.
Weiterhin sollte es selbstverständlich sein, dass bei der Entwicklung von technischen Standards IT-Sicherheit generell berücksichtigt wird. Erst recht gilt das für Standards, die durch Regulierungen und Gesetze verwendet werden müssen. Ein Abschnitt über Sicherheit ist in der Welt der Internet-Standards übliche Praxis (häufig als "Security Considerations" bezeichnet). Derartiges findet sich weder im europäischen Standard EN 16931 der CEN, noch in den deutschen Standards Xrechnung oder ZUGFeRD.
Der Autor hat auf dem German OWASP Day 2025 einen Vortrag zum Thema gehalten(öffnet im neuen Fenster) . Weitere Informationen sowie einen Überblick über die gefundenen Sicherheitslücken sind hier zu finden(öffnet im neuen Fenster) .
IMHO ist der Kommentar von Golem. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach)