Wenn elektronische Rechnungen zur Sicherheitsfalle werden

Elektronische Rechnungen sollen Prozesse vereinfachen und effizienter machen. In der Praxis zeigt sich jedoch: Ihre Einführung ist unnötig kompliziert geraten – und sicherheitstechnisch problematisch.

Papierrechnungen und einfache PDFs sollen in der EU schrittweise durch maschinenlesbare Rechnungsformate ersetzt werden. Die Grundlage dafür wurde bereits 2014 mit der europäischen eInvoicing-Richtlinie gelegt. Im öffentlichen Sektor ist die E-Rechnung schon länger Pflicht: Wer seit 2020 Leistungen für Bundesbehörden erbringt, muss Rechnungen in einem unterstützten elektronischen Format einreichen.

Ab 2025 betrifft die elektronische Rechnungsstellung auch den B2B-Bereich, wenn auch mit Übergangsregelungen und Ausnahmen. Die Richtung ist dennoch eindeutig: Unternehmen müssen künftig elektronische Rechnungen empfangen und erstellen können. Neben Effizienzgewinnen soll dies auch helfen, Umsatzsteuerbetrug EU-weit besser zu bekämpfen.

Grundsätzlich ist diese Entwicklung sinnvoll. Maschinenlesbare Rechnungen bieten klare Vorteile. Die konkrete Umsetzung jedoch ist technisch überladen und lässt zentrale Sicherheitsaspekte vermissen.

Ein „Standard“, der keiner ist

Auf europäischer Ebene gilt für E-Rechnungen der Standard EN 16931 – wobei der Begriff „Standard“ irreführend ist. Tatsächlich handelt es sich um eine Art Meta-Standard, unter dem sich zahlreiche Syntaxen, Profile, Einschränkungen und Erweiterungen versammeln.

EN 16931 wurde vom Europäischen Komitee für Normung (CEN) entwickelt. Zunächst definiert er lediglich, welche Inhalte eine elektronische Rechnung enthalten muss. In weiteren Spezifikationen werden diese Inhalte dann auf konkrete technische Formate abgebildet.

Für den öffentlichen Sektor sind zwei XML-Syntaxen verpflichtend: CII (Cross Industry Invoice) und UBL (Universal Business Language). Darüber hinaus können optionale Syntaxen, sogenannte CIUS-Einschränkungen sowie Erweiterungen definiert werden.

In Deutschland existiert mit XRechnung ein EN-16931-konformer Standard, der zugleich eine CIUS und eine Erweiterung darstellt. Er wurde von der Koordinierungsstelle für IT-Standards (KoSIT) entwickelt. Parallel dazu gibt es mit ZUGFeRD einen weiteren deutschen Standard, der unterschiedliche Profile umfasst – einige kompatibel mit EN 16931, andere nicht. Ein spezielles ZUGFeRD-Profil ist wiederum mit XRechnung kompatibel.

Das Ergebnis ist ein kaum überschaubares Geflecht aus Standards, Varianten und Sonderregeln.

Unnötige technische Komplexität

Die Verwirrung ist nachvollziehbar: Dieses System ist deutlich komplexer, als es sein müsste. Zwar ist eine gewisse Komplexität aufgrund steuerlicher und rechtlicher Rahmenbedingungen unvermeidlich – insbesondere bei europaweiten Regelungen. Doch nichts rechtfertigt, dass identische Inhalte parallel in mehreren Syntaxen abgebildet werden.

Die Ursache liegt vermutlich weniger in technischen Notwendigkeiten als in politischen Kompromissen: Statt sich auf eine einheitliche Lösung zu einigen, wurden mehrere konkurrierende Formate zugelassen.

In Deutschland verstärkt sich dieses Problem durch die parallele Existenz von XRechnung und ZUGFeRD. Während ZUGFeRD auf CII setzt und ein hybrides Modell nutzt – PDF plus eingebettetes XML –, verfolgt XRechnung konsequent den Ansatz eines rein maschinenlesbaren Formats.

Das Hybridmodell ist praxisnah, da PDFs weiterhin für Menschen lesbar sind. Es birgt jedoch Risiken: So können PDF-Darstellung und XML-Inhalt voneinander abweichen – mit potenziell gravierenden Folgen.

Eine Vereinfachung ist nicht in Sicht. Im Gegenteil: EN 16931 soll künftig um eine dritte Syntax (EDIFACT) erweitert werden – auf Druck der Industrie, die dieses Format bereits intensiv nutzt.

Ein Ökosystem mit Qualitätsproblemen

Wer sich mit dem E-Rechnungsumfeld beschäftigt, stößt immer wieder auf Merkwürdigkeiten: defekte Links, fehlerhafte Downloads, nicht funktionierende Beispielsoftware oder widersprüchliche Informationen auf offiziellen Webseiten.

Selbst bei grundlegenden Dokumenten zum EN-16931-Standard ist der Zugang unnötig kompliziert. Kostenlose Teile sind schwer auffindbar, Verlinkungen veraltet, Downloads oft nur über nationale Normungsinstitute und mit Benutzerkonten möglich. Kurios: Die englische Version desselben Standards ist je nach herausgebender Organisation kostenpflichtig oder kostenlos erhältlich.

Hinzu kommen fachlich fragwürdige Details, etwa Rundungsregeln, die bestimmte Bruttopreise rechnerisch unmöglich machen.

XML als strukturelles Sicherheitsproblem

Alle gängigen E-Rechnungsformate – ob XRechnung, ZUGFeRD, CII, UBL oder EDIFACT – basieren auf XML. Dieses Format stammt aus einer Zeit, in der Funktionsvielfalt wichtiger war als Sicherheit.

XML ist inhärent risikobehaftet. Insbesondere die Verarbeitung sogenannter Entities eröffnet Angriffsmöglichkeiten. Bekannt sind unter anderem Denial-of-Service-Angriffe wie der „Billion-Laughs-Angriff“, aber auch deutlich gefährlichere XXE-Angriffe (XML External Entity Injection), mit denen Angreifer Dateien auslesen oder Daten exfiltrieren können.

Zwar haben viele Programmiersprachen ihre Standard-Parser in den letzten Jahren abgesichert. Doch ausgerechnet Java – im Behörden- und Enterprise-Umfeld weit verbreitet – ist in der Standardkonfiguration weiterhin anfällig.

Zusätzliche Risiken durch offizielle Validierungswerkzeuge

Die EU stellt sogenannte Validierungsartefakte bereit, mit denen sich Rechnungen gegen EN 16931 prüfen lassen. Diese Artefakte basieren auf Schematron und werden in XSLT 2.0 übersetzt.

Das Problem: XSLT 2.0 wird praktisch nur von einer frei verfügbaren Implementierung unterstützt – der Java-Bibliothek Saxon. Und auch Saxon ist standardmäßig für XXE-Angriffe verwundbar. Laut den Entwicklern ist keine Änderung dieses Verhaltens geplant.

Damit entsteht eine gefährliche Kombination: XML-basierte Rechnungen, Java-basierte Verarbeitung und eine Validierungsbibliothek mit bekannten Sicherheitsrisiken. Wer diese Zusammenhänge nicht kennt, setzt seine Software unbewusst Angriffen aus.

Im Rahmen der Recherche wurden 13 konkrete XXE-Sicherheitslücken in verschiedenen frei zugänglichen Tools und Online-Diensten entdeckt und gemeldet. Die Dunkelziffer dürfte deutlich höher liegen.

Fazit

Maschinenlesbare Rechnungen sind sinnvoll. Doch durch Entscheidungen in der Standardisierung ist ein System entstanden, das unnötig komplex und sicherheitstechnisch hoch problematisch ist.

Kurzfristig müssen bestehende Sicherheitslücken erkannt und geschlossen werden. Softwarehersteller sollten ihre Produkte gezielt auf XXE-Schwachstellen prüfen. Langfristig braucht es jedoch grundlegendere Konsequenzen.

Für neue Standards sollten keine XML-basierten Formate mehr verwendet werden. Alternativen wie JSON sind zwar nicht perfekt, aber deutlich weniger anfällig. Ebenso selbstverständlich sollte es sein, IT-Sicherheit von Beginn an in technische Standards zu integrieren. In vielen Internetstandards sind „Security Considerations“ üblich.

Quelle: Golem