Nice that they do this since europeans are obsessed with their invoices.
Security issues with electronic invoices
31–40 of 67 posts
Re: Security issues with electronic invoices
#32Earlier quoted context omitted.
In the EU there is the "reverse charge" mechanism for VAT when commerce crosses country borders, and it is often used for defrauding EU countries / governments. The invoicing standard is an attempt to mitigate reverse charge fraud by gathering more machine-readable data. Some countries even demand that b2b invoices are sent to the country, which then dispatches a copy to the recipient. Knowing this background, it's p…
As I understood it, this _is_ the standard that won. It's not like the EU invented it.
As far as I understand there are multiple XML invoice formats and EN 16931 accepts at least two: UBL and CII. At least in theory. I have no idea how it is going to work out in practice, but I will learn the hard way :-) I have invoicing software as side-project and I have decided to make it usable in EU.
Re: Security issues with electronic invoices
#33This 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…
> 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”: … }Re: Security issues with electronic invoices
#34Funny 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 please feel free to reach out to me :)
Re: Security issues with electronic invoices
#35Any reason why they wouldn’t use EDIFACT instead?
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).
Re: Security issues with electronic invoices
#36How 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?
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
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).
Re: Security issues with electronic invoices
#37Funny 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.
Re: Security issues with electronic invoices
#38This 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.
Re: Security issues with electronic invoices
#39What 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.
Re: Security issues with electronic invoices
#40This 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
It's effectively what the Java jar is.