E-Rechnung und ZUGFeRD: Sollen Menschen XML und PDF vergleichen – srsly?
Zwar ist die Pflicht zur E-Rechnung grundsätzlich eine gute Idee und längst überfällig, für Sicherheitsexperten stellen sich allerdings kritische Fragen.
- Janis König
Deutschland digitalisiert weiter: Sogar Rechnungen sind nun endlich digital! Ich wäre aber nicht ich, hätte ich daran nichts auszusetzen. Aber fangen wir langsam an: Dass die Rechnungsstellung digitalisiert wird, ist begrüßenswert, um nicht zu sagen überfällig. Darüber hinaus nicht eine bestimmte Software vorzuschreiben, sondern ein standardisiertes XML-Format, ist ebenfalls der richtige Weg.
In dieser Kolumne soll es aber um Security gehen – und jede Person, die schon einmal einen Applikations-Pentest oder Code-Audit eines XML-basierten Datenaustauschformats durchgeführt hat, hat zu Technologien auf Basis dieser Sprache eine recht gefestigte Meinung. Man möge nur die beiden "OWASP Cheat Sheets" zu XML kurz durchscrollen, die auch so schon recht lang sind. Zu XML gibt es viel zu sagen – und noch viel mehr falsch zu machen. Bei Security geht es ja nicht immer nur um Malware, sondern auch um Datenintegrität. Und wenn man bei literarischen Werken gerne sagt, dass die Aussage immer Interpretationssache ist, gilt das – leider – auch durchaus für XML. Programmierbibliotheken zu XML gibt es viele, Einigkeit über den eigentlichen Dateninhalt herrscht nicht immer. Und auch die Bibliotheken werden nicht immer genutzt, es gibt genug "XML-Parser", die versuchen, das gesamte XML mittels RegEx zu verarbeiten *schauder*.
Unnötige Redundanz
Um das Problem noch viel interessanter zu machen, soll bei ZUGFeRD, dem Zentralen User Guide des Forums elektronische Rechnung Deutschland, der Versand der Rechnungsdaten "grundsätzlich in Form eines PDF-Dokuments, welches die Sichtkomponente der Rechnung" darstellt, erfolgen und ein "inhaltlich identisches Mehrstück derselben Rechnung (XML) innerhalb des PDF mitversandt" werden. Und während es durchaus wünschenswerte Redundanz gibt (beispielsweise in Form von Backups), ist das redundante Halten oder Versenden derselben Daten in unterschiedlichen Formaten in der Regel ein Quell der Freude – für jedes Audit.
Das Forum elektronische Rechnung Deutschland (FeRD) empfiehlt sogar, "eigene Prüfmechanismen zur Sicherstellung der inhaltlichen Identität der beiden Rechnungen einzuführen". Während ich dachte, wir führen digitale Rechnungen ein, um danach zumindest den Versand und die weitere Bearbeitung (also alles außer der inhaltlichen Prüfung) maschinell und automatisch durchzuführen, ist bei ZUGFeRD wohl eher vorgesehen, dass ein Mensch das PDF manuell mit den maschinell lesbaren Daten in einem glorifizierten XML-Viewer vergleicht. Oder vielleicht mit KI?
Vom FeRD erzählt
An anderer Stelle betont FeRD zumindest auch die Möglichkeit, als Rechnungsempfänger ausschließlich mit PDF oder mit XML zu arbeiten. Welche Daten verbindlich sind, hinge vom "Prüfprozess einer Eingangsrechnung ab", sprich, ob der Empfänger PDF oder XML benutzt. Wird jedoch beides genutzt, ist Pandoras Pferdebox offen.
Es gibt also noch Hoffnung, dass wir nicht komplett in Teufels Küche landen, aber es gibt doch genug Falltüren und Fehler, die begangen werden können. Genug Möglichkeiten für externe Consultants, damit Geld zu verdienen, Awareness-Schulungen zu geben und überfordertem Büropersonal teuer zu erklären, wie es dazu kommen kann, dass im PDF eine andere Zahl steht, als dann automatisch abgebucht wird. Wir, die Security-Branche, nehmen das Geld natürlich gern. Aber sollte Technologie nicht eigentlich so gebaut sein, dass man solche Fehler gar nicht erst begehen kann?
(pst)
