电子发票的安全问题
Security issues with electronic invoices

原始链接: https://invoice.secvuln.info/

## 欧盟电子发票指令:安全隐患 本次演示在德国OWASP Day 2025上发表,重点介绍了欧盟电子发票指令(2014/55/EU)及其实施中存在的重大安全缺陷。该指令旨在标准化电子发票(XML格式),但由于其复杂性、缺乏真正的标准化以及对不安全技术的依赖而存在问题。 主要担忧在于XML本身固有的XXE(XML外部实体)注入攻击漏洞,可能导致数据泄露。关键是,电子发票生态系统内常用的库——Java和Saxon——默认情况下都存在漏洞。为了符合合规性验证,必须使用XSLT 2.0,这进一步加剧了问题,因为Saxon是目前唯一的免费实现。 研究表明,许多电子发票软件包(kivitendo、peppol-py、ZUV、papierkram.de等)都存在XXE漏洞,其中许多已得到修复。然而,仍有一些漏洞未解决或修复不完全。令人惊讶的是,访问定义这些要求的EN16931标准也十分困难。 提供了一个安全测试套件,以帮助识别这些漏洞。本次演示强调了在实施电子发票解决方案时提高安全意识和采取强有力对策的必要性。

## 电子发票安全问题 - 摘要 最近Hacker News上的讨论强调了电子发票中的安全漏洞,特别是使用EN 16931和UBL等XML标准的情况。虽然许多攻击途径已为人们所知十年之久,但仍然在实现中(如SAP)发现漏洞,引发了对数据安全的担忧。 核心问题在于XML的复杂性和潜在的可利用性——引用外部实体或本地文件——尽管存在数字签名方法。争论的中心在于JSON或Protobuf等替代方案是否能提供更好的安全性,以及对这些格式进行数字签名的挑战。 欧盟正在强制实施电子发票,但人们担心获取标准的成本以及市场可能因多个私有平台而碎片化。一些人认为,为了效率和防止欺诈(特别是增值税欺诈),标准化格式是必要的,而另一些人则批评自上而下的方法,并更喜欢新兴标准。 许多开发者已经在致力于开发开源解决方案来支持新的要求。
相关文章

原文

This page provides supplementary material for a presentation given at the German OWASP Day 2025 (Presentation Slides).

Intro

With the eInvoicing Directive (2014/55/EU), the European Union introduced “standardized” electronic invoices in XML format. Increasingly, institutions and businesses in EU member states will be required to support these electronic invoices.

While machine-readable invoices are, in general, a good idea, there are various issues with the EU’s approach, including needless complexity, a lack of true standardization (multiple syntaxes and various sub-formats), and a tendency to use technologies with inherent security problems.

Due to a combination of unfortunate design decisions, implementing software for electronic invoices is likely to be affected by security flaws if no countermeasures are implemented.

XML Insecurity and XXE

The XML format is known to have inherent security flaws, the most dangerous ones being XXE vulnerabilities (XML eXternal Entity injection).

XXE vulnerabilities often allow the exfiltration of files. While some XML implementations have implemented secure defaults or were never vulnerable to begin with (e.g., Python, libxml2, .NET, Expat), others remain insecure by default.

Two notable examples of implementations with insecure defaults are the Java standard library and the Saxon library. Both are commonly used within the electronic invoicing ecosystem.

The problem with XSLT 2.0

XSLT is a document transformation language. Only XSLT version 1.0 is widely supported. For XSLT 2.0 and above, only one freely available implementation exists: Saxon.

To check compliance with the EN16931 standards, the EU provides validation artifacts based on Schematron. Those validation artifacts require XSLT 2.0.

Thus, anyone using these validation artifacts will likely use Saxon to implement invoice parsing. Saxon, as mentioned, is vulnerable to XXE by default.

Despite its poor implementation status and the fact that its primary implementation has insecure defaults, XSLT 2.0 (and its successor 3.0) is a W3C recommendation. I raised these concerns with the W3C.

Security test suite

A security test suite for electronic invoices is provided here.

Getting the EN16931 standards

The EU requirements for electronic invoices are standardized by the European Committee for Standardization (CEN) in a set of standards named EN16931. The first two parts are available free of charge. Subsequent parts cost money.

Accessing these standards is surprisingly difficult. A link on the EU web page to CEN is currently broken. CEN does not provide direct downloads of these documents and refers to national standardization organizations. Those often require account registrations even to access the free-of-charge parts of the standard.

The Estonian standardization organization (EVS) provides downloads of parts one and two without registration:

For the parts of EN16931 that are not available free of charge, prices at EVS are cheaper than those at most other national standardization organizations.

XXE vulnerabilties

List of security vulnerabilities discovered in electronic invoicing software during this research:

Product Vuln type Info
kivitendo XXE Reported 2025-03-25, Fixed in 3.9.2beta (2025-03-28) / 3.9.2 (2025-05-05), Software Stack: Perl/XML::LibXML, CVE-2025-66370
peppol-py Blind XXE Reported: 2025-11-13, fixed in 1.1.1 (2025-11-13), Software Stack: Python/Saxon, CVE-2025-66371
ZUV* Blind XXE Reported: 2025-11-17, no longer developed according to README, Software Stack: Java/Saxon
papierkram.de E-Rechnung-Viewer XXE Reported: 2025-03-30, fixed: 2025-03-31
EPO E-Invoice Viewer XXE Reported: 2025-10-13, fixed: 2025-10-14
portinvoice XXE Reported: 2025-10-29, fixed: 2025-10-29
xrechnung-erstellen.com E-Rechnung Viewer XXE Reported: 2025-10-14, fixed: 2025-10-16
Belegmeister ZUGFERD VIEWER Blind XXE Reported: 2025-11-15 (only supports PDF upload), fixed: 2025-11-25
E-Rechnungs-Validator by winball.de Blind XXE Reported: 2025-11-17, fixed: 2025-11-19, confirmation
ZUGFeRD Community ZF/FX Invoiceportal Blind XXE Reported: 2025-11-17, no reply, re-tested on 2025-11-25, validation functionality was removed (relied on ZUV)
REDACTED1 XXE Reported: 2025-10-29, no reply, re-tested on 2025-11-18, fix incomplete (see next line)
REDACTED1 Blind XXE Reported: 2025-11-18, no reply, unfixed
REDACTED2 Blind XXE Reported: 2025-11-17, no reply, unfixed

* ZUV is no longer developed, and it is recommended to use Mustang instead. Mustang was also vulnerable to XXE in versions before 2.16.3 (CVE-2025-66372).

More

Questions?

Get in touch!

Text and logo are licensed as CC0. The logo is a mix of three icons from svgrepo.com, all CC0. The web page uses Pico CSS (MIT license) and Hugo.

Created by Hanno Böck (created: , last update: )

Imprint

联系我们 contact @ memedata.com