Live data from Hacker News

Security issues with electronic invoices

invoice.secvuln.info

41–50 of 67 posts

Re: Security issues with electronic invoices

#41
post #37
post #34

Funny enough, I’m currently adding e-invoice support to my open-source invoice generator. Github: https://github.com/VladSez/easy-invoice-pdf App: https://easyinvoicepdf.com/?template=stripe I’m planning to use this package to generate e-invoice: https://github.com/gflohr/e-invoice-eu UPD: issue to follow the progress https://github.com/VladSez/easy-invoice-pdf/issues/121 If you have any feedback or suggestions pleas…

Thanks. I was about to write something of mine own, but if there is something already for e-invoicing, then maybe it is even easier to implement.

Yeah, this package seems very useful.

Re: Security issues with electronic invoices

#42

A standard for invoices seems like something that an accounting body should create that is optional for businesses, not something mandatory created by the government. People will generally follow an optional standard to make their own lives easier, but a mandatory one introduces a compliance middleman into the invoicing process.

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 companies to adopt eInvoicing (i.e. more carrot, less stick.)

The EU has a solid trend of finding ways to self-harm when introducing reforms. This self-harm story segue's into how the EU is considering implementing an Australian-style social media restriction for children:

Quote from abc.net.au below:

European Commission president Ursula von der Leyen told the audience she had been "inspired" by Australia's "bold" move to introduce the ban.

"As a mother of seven children and grandmother of five, I share their view," she said.

The European Parliament has since passed a non-legislative report that would set a minimum age of 16 for social media, while allowing those aged 13 to 15 with parental consent.

-- end quote --

Here the EU is walking down the path of another bad implementation.

Limiting the age for social media only works if it's mandatory for all children, otherwise kids will just pester their parents for access. In the EU's plan the parents become the "bad guy" in that arrangement, the home becomes the battleground for obtaining access to social media.

The EU's plan also means that social media remains relevant for young people, where access may be needed for arranging social activities and sports, and those which don't have it are either inconvenienced or miss out. Meanwhile the Australian implementation removes that purpose as no kids are allowed on the platform, thus there are no "haves" and "have nots" kids.

Finally, and probably most importantly, advertisers, data brokers, and bad actors will still continue to target children through social media networks, since they will still be there in useful numbers.

Re: Security issues with electronic invoices

#43

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-----

Re: Security issues with electronic invoices

#44

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…

Other answers are good. One more that you could do is put the JSON document inside a container (A zip archive for example). Then your document can effectively be invoice.inv (zip archive) └- payload.json └- signature.asc This has the benefit of adding more opportunities for many json documents within the archive. It's effectively what the Java jar is.

dont unzip an untrusted payload

Re: Security issues with electronic invoices

#45

Earlier quoted context omitted.

Other answers are good. One more that you could do is put the JSON document inside a container (A zip archive for example). Then your document can effectively be invoice.inv (zip archive) └- payload.json └- signature.asc This has the benefit of adding more opportunities for many json documents within the archive. It's effectively what the Java jar is.

dont unzip an untrusted payload

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.

Re: Security issues with electronic invoices

#46
post #38

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…

If one has a reproducible JSON serializer, then one can add a signature to any JSON object via serializing the object, signing that and then adding the resulting signature to the original object. This avoids JSON-inside-JSOn and allows to pretty-print the original object with the signature.

> If one has a reproducible JSON serializer

Pretty significant catch if interoperability is a concern at all. Whitespace is easy enough to handle but how do dict keys get ordered? Are unquoted numbers with high precision output as-is or truncated to floats/JS Numbers? Is scientific notation ever used and if so when?

Re: Security issues with electronic invoices

#47

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 Protobuf or XML or anything else, turn structured data into strings of bytes, and signature schemes operate on strings of bytes, so you'll have a great time signing data _after_ serializing it.

Re: Security issues with electronic invoices

#48

Earlier quoted context omitted.

I think there’s a difference between _wanting_ something to work and _needing_ something to work. Enforced standardized invoicing might be a very tidy and neat solution, but tidiness and neatness are not a good enough argument to mandate it in my opinion. There’s no end to the areas of our lives that could be regulated if that’s the standard we’re aiming for, and I don’t particularly want to live in such a uniform, s…

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.

Re: Security issues with electronic invoices

#49
post #46
post #38

Earlier quoted context omitted.

If one has a reproducible JSON serializer, then one can add a signature to any JSON object via serializing the object, signing that and then adding the resulting signature to the original object. This avoids JSON-inside-JSOn and allows to pretty-print the original object with the signature.

> If one has a reproducible JSON serializer Pretty significant catch if interoperability is a concern at all. Whitespace is easy enough to handle but how do dict keys get ordered? Are unquoted numbers with high precision output as-is or truncated to floats/JS Numbers? Is scientific notation ever used and if so when?

Just so people this far down can look it up the term is Canonicalization, and its cousin collation.

These are non-trivial issues that, thankfully, some very smart and/or experienced people have usually handled for us. However, they still frequently lead to all sorts of vulnerabilities. "Stuffing" attacks sometimes rely on these issues, as have several major crypto incidents.

Re: Security issues with electronic invoices

#50

Earlier quoted context omitted.

dont unzip an untrusted payload

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

Post reply on HN