7 ms·

Security issues with electronic invoices

92 points by todsacerdoti 11mo ago

blipvert 11mo ago
Any reason why they wouldn’t use EDIFACT instead?
- blipvert 11mo ago
  OK, it’s been a long time since I worked in this space. Seems like it’s an XML version of the INVOIC message, but is it required to support the XML syntax, or does the plain old EDI format suffice?
- tnorgaard 11mo ago
  As having implemented EDIFACT parsers and translation layers, Universal Business Language (Oasis UBL) is a bliss to work with. Yes, it's a big standard and looks scary when starting out with it, but it is very well designed for a complicated world.
- daliusd 11mo ago
  Google says following: In some member states, like Germany, the EDIFACT format, when compliant with the EN 16931 data model, is accepted as a valid e-invoice format. EN 16931 defines what information needs to be in an invoice (the data model), while EDIFACT INVOIC defines how that information is structured and formatted for electronic transmission (the syntax).
esher 11mo ago
Another project by Hanno Böck: https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sAiR https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sA...
moffkalast 11mo ago
How can there be security issues with a public document? Can't you just sign it with a cert like any other piece of data that needs a proven source? But also let me get this straight, there is an actual EU standard for invoices? Why the does nobody follow this and I have to keep asking people to put the fucking VAT ID onto it like I'm a broken record?
- rullera 11mo ago
  States have not starting to enforce them until recently. As I understand it the goal is to have all members using them in a couple of years time
  - daliusd 11mo ago
    Actually, it's not universal and depends if it is B2G, B2B or B2C. The last one (B2C) is not enforced basically in EU (except Romania, but there is no EU requirement for B2C).
- IncreasePosts 11mo ago
  Because when some things parse the document they do things like read files from the OS as specified in the document
- Analemma_ 11mo ago
  The concern is that a malicious vendor could send you an evil invoice where the XML either references external entities that get downloaded and allow potential RCE, or where the document contains references to the local execution environment which allow data exfiltration (or both). In theory a properly-secured XML parser shouldn't allow this, but history has shown that's harder than you might think.
clickety_clack 11mo ago
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.
- victorbjorklund 11mo ago
  The accountancy bodies are national so it would end up with one standard per country. But yea should probably not be mandatory.
  - quitit 11mo ago
    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.
encom 11mo ago
[flagged]
not-so-darkstar 11mo ago
[flagged]
- downboots 11mo ago
  https://en.wikipedia.org/wiki/Tonsure https://en.wikipedia.org/wiki/Tonsure
  - not-so-darkstar 11mo ago
    goes hard
VoidWhisperer 11mo ago
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
- a3w 11mo ago
  DIN is not a government; CEN is an NGO, too. But yes, for commercial offers, presumption of conformity mean you have to pay for norms to adhere to law. Big fail. Especially since non-commercial but persistent and public, not "for profit", is still surmised in e.g. warranty laws. (E.g. geschäftsmäßige Nutzung / usage with said two terms, even for F/LOSS)
- TheJoeMan 11mo ago
  The right to access standards that have been incorporated-by-reference into law is still being established by various countries' court systems. For example, in the USA https://www.rcfp.org/briefs-comments/astm-v-upcodes-inc/ https://www.rcfp.org/briefs-comments/astm-v-upcodes-inc/ This is an especially hot topic in the EU in medical device regulations: https://www.bsigroup.com/en-GB/insights-and-media/insights/blogs/ecj-ruling-c-588-21-p/ https://www.bsigroup.com/en-GB/insights-and-media/insights/b...
- looperhacks 11mo ago
  To be clear: The ones who need to follow the standard (companies that create invoices) do not need access to the standard, only some supplier does. And there are a lot of things that the government requires that costs money - you could see it as another tax. That said, I actually agree with you - it's crazy that we need to pay for a stupid standard document.
- isodev 11mo ago
  > 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.
tnorgaard 11mo ago
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 document? The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/master/src/main/resources/org/oasis-open/ubl/examples https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.
- vlovich123 11mo ago
  > How would you digitally sign a Json document and embed the signature in the document? Presumably the same way you accomplish the thing in xml: { “signature”: “…”, “payload”: … }
- fpoling 11mo ago
  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.
  - baobun 11mo ago
    > 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?
daft_pink 11mo ago
Nice that they do this since europeans are obsessed with their invoices.
vldszn 11mo ago
Funny enough, I’m currently adding e-invoice support to my open-source invoice generator. Github: https://github.com/VladSez/easy-invoice-pdf https://github.com/VladSez/easy-invoice-pdf App: https://easyinvoicepdf.com/?template=stripe https://easyinvoicepdf.com/?template=stripe I’m planning to use this package to generate e-invoice: https://github.com/gflohr/e-invoice-eu https://github.com/gflohr/e-invoice-eu UPD: issue to follow the progress https://github.com/VladSez/easy-invoice-pdf/issues/121 https://github.com/VladSez/easy-invoice-pdf/issues/121 If you have any feedback or suggestions please feel free to reach out to me :)
- daliusd 11mo ago
  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.
  - vldszn 11mo ago
    Yeah, this package seems very useful.
idoubtit 11mo ago
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 recipient. The business sends the invoice to a registered go-between, which will ask a national platform for the address of the recipient's go-between, etc. So, only those official go-between companies will have to securely parse the XML. BTW, in 2022 when the French government decided to make e-invoicing mandatory, it announced that it would develop a national unique go-between platform. Two years later, it dropped that part of the project and announced that there would be an official list of private platforms. So, by the end of 2026 or 2027, every French business will have to select one of the 112 platforms and buy a subscription. It give the State more control, but for small businesses it means higher costs and complexity.
- dr_faustus 11mo ago
  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.

92 points by todsacerdoti 11mo ago

blipvert 11mo ago

Any reason why they wouldn’t use EDIFACT instead?

blipvert 11mo ago
OK, it’s been a long time since I worked in this space. Seems like it’s an XML version of the INVOIC message, but is it required to support the XML syntax, or does the plain old EDI format suffice?
tnorgaard 11mo ago
As having implemented EDIFACT parsers and translation layers, Universal Business Language (Oasis UBL) is a bliss to work with. Yes, it's a big standard and looks scary when starting out with it, but it is very well designed for a complicated world.
daliusd 11mo ago
Google says following: In some member states, like Germany, the EDIFACT format, when compliant with the EN 16931 data model, is accepted as a valid e-invoice format. EN 16931 defines what information needs to be in an invoice (the data model), while EDIFACT INVOIC defines how that information is structured and formatted for electronic transmission (the syntax).

esher 11mo ago

Another project by Hanno Böck: https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sAiR https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sA...

moffkalast 11mo ago

How can there be security issues with a public document? Can't you just sign it with a cert like any other piece of data that needs a proven source? But also let me get this straight, there is an actual EU standard for invoices? Why the does nobody follow this and I have to keep asking people to put the fucking VAT ID onto it like I'm a broken record?

rullera 11mo ago
States have not starting to enforce them until recently. As I understand it the goal is to have all members using them in a couple of years time
- daliusd 11mo ago
  Actually, it's not universal and depends if it is B2G, B2B or B2C. The last one (B2C) is not enforced basically in EU (except Romania, but there is no EU requirement for B2C).
IncreasePosts 11mo ago
Because when some things parse the document they do things like read files from the OS as specified in the document
Analemma_ 11mo ago
The concern is that a malicious vendor could send you an evil invoice where the XML either references external entities that get downloaded and allow potential RCE, or where the document contains references to the local execution environment which allow data exfiltration (or both). In theory a properly-secured XML parser shouldn't allow this, but history has shown that's harder than you might think.

clickety_clack 11mo ago

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.

victorbjorklund 11mo ago
The accountancy bodies are national so it would end up with one standard per country. But yea should probably not be mandatory.
- quitit 11mo ago
  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.

encom 11mo ago

[flagged]

not-so-darkstar 11mo ago

[flagged]

downboots 11mo ago
https://en.wikipedia.org/wiki/Tonsure https://en.wikipedia.org/wiki/Tonsure
- not-so-darkstar 11mo ago
  goes hard

VoidWhisperer 11mo ago

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

a3w 11mo ago
DIN is not a government; CEN is an NGO, too. But yes, for commercial offers, presumption of conformity mean you have to pay for norms to adhere to law. Big fail. Especially since non-commercial but persistent and public, not "for profit", is still surmised in e.g. warranty laws. (E.g. geschäftsmäßige Nutzung / usage with said two terms, even for F/LOSS)
TheJoeMan 11mo ago
The right to access standards that have been incorporated-by-reference into law is still being established by various countries' court systems. For example, in the USA https://www.rcfp.org/briefs-comments/astm-v-upcodes-inc/ https://www.rcfp.org/briefs-comments/astm-v-upcodes-inc/ This is an especially hot topic in the EU in medical device regulations: https://www.bsigroup.com/en-GB/insights-and-media/insights/blogs/ecj-ruling-c-588-21-p/ https://www.bsigroup.com/en-GB/insights-and-media/insights/b...
looperhacks 11mo ago
To be clear: The ones who need to follow the standard (companies that create invoices) do not need access to the standard, only some supplier does. And there are a lot of things that the government requires that costs money - you could see it as another tax. That said, I actually agree with you - it's crazy that we need to pay for a stupid standard document.
isodev 11mo ago
> 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.

tnorgaard 11mo ago

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 document? The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/master/src/main/resources/org/oasis-open/ubl/examples https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.

vlovich123 11mo ago
> How would you digitally sign a Json document and embed the signature in the document? Presumably the same way you accomplish the thing in xml: { “signature”: “…”, “payload”: … }
fpoling 11mo ago
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.
- baobun 11mo ago
  > 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?

daft_pink 11mo ago

Nice that they do this since europeans are obsessed with their invoices.

vldszn 11mo ago

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

daliusd 11mo ago
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.
- vldszn 11mo ago
  Yeah, this package seems very useful.

idoubtit 11mo ago

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 recipient. The business sends the invoice to a registered go-between, which will ask a national platform for the address of the recipient's go-between, etc. So, only those official go-between companies will have to securely parse the XML. BTW, in 2022 when the French government decided to make e-invoicing mandatory, it announced that it would develop a national unique go-between platform. Two years later, it dropped that part of the project and announced that there would be an official list of private platforms. So, by the end of 2026 or 2027, every French business will have to select one of the 112 platforms and buy a subscription. It give the State more control, but for small businesses it means higher costs and complexity.

dr_faustus 11mo ago
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.