Security issues with electronic invoices • Hacker News Board

Re: Security issues with electronic invoices

#61

Post by aleksejs » Sat, Dec 13, 2025, 6:22 PM UTC

BaconVonPork wrote: post #60

aleksejs wrote: post #59

Earlier quoted context omitted.

That is not, in fact, the question. The whole point of storing signatures separately from the serialized bytes they sign is not having to rely on any properties of the serialization scheme. It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it. XML-DSig, to the contrary, requires that you parse the document, apply complex t…

You are saying people shouldn't want what they want and since JSON has no standards for it you assume it won't happen. Not even X509 is interested in working with detached signatures. > It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it. It most certainly does. First or last duplicate key?

I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.

Re: Security issues with electronic invoices

#62

Post by BaconVonPork » Sat, Dec 13, 2025, 7:15 PM UTC

aleksejs wrote: post #61

BaconVonPork wrote: post #60

Earlier quoted context omitted.

You are saying people shouldn't want what they want and since JSON has no standards for it you assume it won't happen. Not even X509 is interested in working with detached signatures. > It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it. It most certainly does. First or last duplicate key?

I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.

When I look at JSON related crypto, say JWT or WebAuthn, I am (un)comfortable saying the CVE causing complexities are there but repeating and not consolidated on a standard layer.

Re: Security issues with electronic invoices

#63

Post by aleksejs » Sat, Dec 13, 2025, 8:00 PM UTC

BaconVonPork wrote: post #62

aleksejs wrote: post #61

Earlier quoted context omitted.

I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.

When I look at JSON related crypto, say JWT or WebAuthn, I am (un)comfortable saying the CVE causing complexities are there but repeating and not consolidated on a standard layer.

I'm not sure why you take me for a JSON/JWT fan (I'm happy to agree they've had their own share of implementation bugs), or what that has to do with signature wrapping bugs in XML-DSig, which is what I've been talking about this entire time.

Re: Security issues with electronic invoices

#64

Post by boston_clone » Sat, Dec 13, 2025, 11:59 PM UTC

cogman10 wrote: post #58

boston_clone wrote: post #50

Earlier quoted context omitted.

hello, https://nvd.nist.gov/vuln/detail/CVE-2025-11001

Right, so long as step 1 in reading your file isn't "extract everything" you're pretty safe. This specific exploit is one that only exists when you are extracting a zip on windows.

this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.

Re: Security issues with electronic invoices

#65

Post by cogman10 » Sun, Dec 14, 2025, 12:32 AM UTC

boston_clone wrote: post #64

cogman10 wrote: post #58

Earlier quoted context omitted.

Right, so long as step 1 in reading your file isn't "extract everything" you're pretty safe. This specific exploit is one that only exists when you are extracting a zip on windows.

this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.

A curious search reveals that vulnerabilities that do exist are of 2 flavors.

1. Standard C memory vulnerabilities

2. Unsafe file traversal while unzipping

The entire second class is avoided in a fixed file format. The first class of vulnerabilities plague everything. A quick look at libxml2 CVEs shows that.

Re: Security issues with electronic invoices

#66

Post by boston_clone » Sun, Dec 14, 2025, 6:51 PM UTC

cogman10 wrote: post #65

boston_clone wrote: post #64

Earlier quoted context omitted.

this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.

A curious search reveals that vulnerabilities that do exist are of 2 flavors. 1. Standard C memory vulnerabilities 2. Unsafe file traversal while unzipping The entire second class is avoided in a fixed file format. The first class of vulnerabilities plague everything. A quick look at libxml2 CVEs shows that.

and the zip bombs you mentioned! i keep a dummy SD card with one hehe.

but yeah the first class of vulns is why we have advice like don’t run untrusted input, which is not dissimilar to “don’t unzip untrusted payloads”.

Re: Security issues with electronic invoices

#67

Post by dr_faustus » Mon, Dec 15, 2025, 12:11 AM UTC

idoubtit wrote: post #39

What was unclear in that article is that the XML is usually embedded in the invoice. For instance, Factur-X is the mandatory format in Germany, and it's a PDF which contains a metadata block with a XML EN16931 content. This XML will usually not be read by the companies that pay the invoice. For instance, in France by the end of 2027, every business will have to send e-invoices, but never directly to the real recipien…

Your statements about Germany are not correct: Factur-X is not common in Germany at all, the German version of this standard (albeit very closely related to Factur-X) is called Zugferd and it is by no means mandatory in Germany.

Actually, most governmental agencies (which have required e-invoices for many years), only accept the pure XML files. Zugferd is a bit of an interim solution until everybody is familiar with an e-invoice visualizer. There are already many free (as in beer and source) solutions available for that. Zugferd (X-Factur) is a problematic standard, because there can be discrepancies between the PDF and the embedded file and its unclear, which is authorative. Concerning the platforms: I don't know about France, but in Germany, sending e-invoices by e-mail is explicitly permitted by the government.