Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security issues with electronic invoices

invoice.secvuln.info

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Security issues with electronic invoices

#51

Post by isbvhodnvemrwvn »

michaelt wrote: post #43
tnorgaard wrote: post #20

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the d…

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > How would you digitally sign a Json document and embed the signature in the document? Embedding a signature into the same file is easy enough. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.7 (GNU/Linux) iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1 oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k =y6kj -----END PGP SIGNATURE-----

Or use something similar to jwts, you normalize the document, sign the hash, wrap the original document with metadata and include the signature.

Re: Security issues with electronic invoices

#52

Post by isodev »

VoidWhisperer wrote: post #16

Aside from the security issue, it seems like an awful idea for a government (or governments, in this case) to say 'hey, you need to follow this standard for invoicing. But also, you have to pay to see the entire standard'.. almost feels like extortion a bit

> it seems like an awful idea for a government

You mean the government that’s already the tax authority for which you create and report invoices? I can promise you it’s a good thing. Electronic invoices are a lot easier for us (obviously since it’s just a click instead of a whole PDF operation). It also removes a whole bunch of possibilities for mistakes.

> you have to pay to see the entire standard

The article is wrong about that though, all technical docs are available via the europa portal and reference implementation examples.

Re: Security issues with electronic invoices

#53

Post by xorcist »

tnorgaard wrote: post #20

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the d…

> XML-DSig isn't great with XPaths

Or at all.

> How would you digitally sign a Json document and embed the signature in the document?

Preferrably you wouldn't because that's a really bad idea.

That said, this type of support-every-conceivable-idea design-by-committee systems would be equally bad built on json or anything else. That much is true.

There's probably no silver bullet here. But that is still not an excuse for XML-Sig.

Re: Security issues with electronic invoices

#54

Post by victorbjorklund »

quitit wrote: post #42
victorbjorklund wrote: post #13

Earlier quoted context omitted.

The accountancy bodies are national so it would end up with one standard per country. But yea should probably not be mandatory.

Other major countries that have adopted eInvoicing have kept it optional for a few reasons: - It's a barrier for small businesses, or those which seldomly invoice, such as craft and hobby businesses (particularly remote online businesses). - Large companies see eInvoicing as a cost saving method and force it upon their vendors. This reduces the need to make it mandatory and provides a financial incentive for companie…

Yea, but EU can of course have a common standard and not make it mandatory. It’s not more strange than US making federal standard vs different standards in each state.

Re: Security issues with electronic invoices

#55

Post by quitit »

victorbjorklund wrote: post #54
quitit wrote: post #42

Earlier quoted context omitted.

Other major countries that have adopted eInvoicing have kept it optional for a few reasons: - It's a barrier for small businesses, or those which seldomly invoice, such as craft and hobby businesses (particularly remote online businesses). - Large companies see eInvoicing as a cost saving method and force it upon their vendors. This reduces the need to make it mandatory and provides a financial incentive for companie…

Yea, but EU can of course have a common standard and not make it mandatory. It’s not more strange than US making federal standard vs different standards in each state.

Yes I agree, and this would be the ideal and most efficient outcome, and it should be repeated: an EU-wide common standard, which can then be optionally adopted by businesses in each member state alongside not forbidding existing invoicing methods.

In this scenario we can anticipate that business practices will shift to the common standard over time, and that would include the accounting software used by new businesses: resulting in a phased conversion with minimal disruptions to running a business.

Re: Security issues with electronic invoices

#56

Post by autoexec »

clickety_clack wrote: post #48
autoexec wrote: post #27

Earlier quoted context omitted.

Would you rather governments insist on everyone using the same format when invoices are passed around or would you rather have massive amounts of taxpayer money wasted on managing countless conflicting standards, any number of which may also include their own security issues. At a certain scale it just makes sense to say "Okay everyone, we have to pick one way to do this". If tidiness and neatness are not a good enou…

Have you ever actually dealt with invoices? I have hired many many contractors in construction and tech, and I’ve never thought it to be that bad. Definitely not enough of a mess to justify another rule for how I’m supposed to run a business.

Did you have to deal with invoices from companies across 27+ different countries? Did you automate any of it at all?

Scale is a much bigger deal than the complexity of any one invoice. When you're dealing with hundreds of thousands if not millions of invoices from all over the place it makes sense to have it standardized so that software can be developed to do most your work with those invoices automatically and consistently.

I've worked on automating high volume document processing from a much smaller number of companies (mainly just from those within the US), just one or two outliers can massively expand your codebase and when those companies are free to change their formats on a whim in whatever why suits them it can break everything in ways that can be immediately catastrophic or very subtle but no less disastrous.

Re: Security issues with electronic invoices

#57

Post by BaconVonPork »

aleksejs wrote: post #47
tnorgaard wrote: post #20

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the d…

Most of these attack vectors have been known for 10 years, and yet researchers keep finding bugs in major implementations to this day. Here's one from last week: https://portswigger.net/research/the-fragile-lock > How would you digitally sign a Json document and embed the signature in the document? You would not, because that's exactly how you get these bugs. Fortunately serialization mechanisms, whether JSON or Prot…

This seems like a distinction without meaning. The question is whether JSON serializations intended for canonical signing would be somehow safer than those XML serializations. Obviously people would like all the same features that caused problems before.

Re: Security issues with electronic invoices

#58

Post by cogman10 »

boston_clone wrote: post #50
cogman10 wrote: post #45

Earlier quoted context omitted.

Unless you are worried about something like a gzip bomb, I don't see why this is an issue. A lot of formats are effectively just zips. The xlsx, odf, etc for example. It's a pretty common format style. It helps to have a well defined expected structure in the archive.

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.

Re: Security issues with electronic invoices

#59

Post by aleksejs »

BaconVonPork wrote: post #57
aleksejs wrote: post #47

Earlier quoted context omitted.

Most of these attack vectors have been known for 10 years, and yet researchers keep finding bugs in major implementations to this day. Here's one from last week: https://portswigger.net/research/the-fragile-lock > How would you digitally sign a Json document and embed the signature in the document? You would not, because that's exactly how you get these bugs. Fortunately serialization mechanisms, whether JSON or Prot…

This seems like a distinction without meaning. The question is whether JSON serializations intended for canonical signing would be somehow safer than those XML serializations. Obviously people would like all the same features that caused problems before.

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 transformations to it, and then reserialize it before you can verify anything, which is what makes bugs like "oops the canonicalization method errored and now my library will accept a signature over the empty string as valid for any document" (https://portswigger.net/research/the-fragile-lock#void-canon...) possible.

Re: Security issues with electronic invoices

#60

Post by BaconVonPork »

aleksejs wrote: post #59
BaconVonPork wrote: post #57

Earlier quoted context omitted.

This seems like a distinction without meaning. The question is whether JSON serializations intended for canonical signing would be somehow safer than those XML serializations. Obviously people would like all the same features that caused problems before.

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?

Post reply on HN