[HN Gopher] Security issues with electronic invoices
___________________________________________________________________
Security issues with electronic invoices
Author : todsacerdoti
Score : 57 points
Date : 2025-12-12 20:28 UTC (2 hours ago)
(HTM) web link (invoice.secvuln.info)
(TXT) w3m dump (invoice.secvuln.info)
| blipvert wrote:
| Any reason why they wouldn't use EDIFACT instead?
| blipvert wrote:
| 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 wrote:
| 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.
| esher wrote:
| Another project by Hanno Bock:
| https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sA...
| moffkalast wrote:
| 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 wrote:
| 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
| IncreasePosts wrote:
| Because when some things parse the document they do things like
| read files from the OS as specified in the document
| Analemma_ wrote:
| 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 wrote:
| 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.
| plantain wrote:
| That's just not how the EU functions.
| victorbjorklund wrote:
| The accountancy bodies are national so it would end up with one
| standard per country. But yea should probably not be mandatory.
| croes wrote:
| If you want something to work in multiple countries, you have
| little choice. Otherwise you x standards
| clickety_clack wrote:
| 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, straightjacketed environment.
| autoexec wrote:
| 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 enough argument to
| mandate this taxpayer savings, time efficiency, and better
| software should be.
|
| Companies who insist on being precious about their favored
| invoice format can invest their own time and money on
| conversion tools that let them convert invoices they get
| into whatever format they like for their own internal
| records and convert them to meet the standard again when
| sending invoices out. That leaves them free to use what
| they want without making everyone else deal with their
| mess.
| Fraaaank wrote:
| Electronic invoicing makes the live of the receiver easier. The
| sender has to adapt the standard.
|
| Besides, many standards have been created over the past 20
| years, yet most invoices are still only sent as PDF.
| autoexec wrote:
| > People will generally follow an optional standard to make
| their own lives easier
|
| People invent their own standard to make their own lives easier
| at the cost of making everyone else's lives miserable which is
| exactly what the European Committee for Standardization was
| intended to prevent.
| perlgeek wrote:
| 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 pretty clear why the EU is making
| it mandatory.
|
| Personally, in the abstract I like the idea to mandate the use
| of an open standard, I think we have way too many
| inefficiencies from treating many things as text documents that
| could be data structures. I don't like this particular standard
| though, it's bloated and the result of a typical top-down
| process.
|
| I much prefer it when there are competing standards for a
| while, and one or a couple of winner emerge on technical
| merits. THEN I have no objections to a regulatory body picking
| a standard and mandating it.
| looperhacks wrote:
| As I understood it, this _is_ the standard that won. It's not
| like the EU invented it.
| daliusd wrote:
| 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.
| looperhacks wrote:
| > People will generally follow an optional standard to make
| their own lives easier
|
| You must be new to the internet /s
|
| A company does not gain anything by sending "better" invoices
| that follow a standard. Only if they receive standardized
| invoices, but usually not enough to pay extra for it. The fact
| that standardized invoices haven't happened yet without
| legislation should be proof of that
| cogman10 wrote:
| Having worked with accounting body standards (NAIC), I can tell
| you that it really does nothing to improve quality. Especially
| when parts of the standard encode things like COBOL PIC number
| symbols. [1]
|
| [1] https://www.ibm.com/docs/en/cobol-
| zos/6.4.0?topic=arithmetic...
| encom wrote:
| >European Union
|
| >needless complexity
|
| First time?
| VoidWhisperer wrote:
| 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 wrote:
| 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.
| geschaftsmassige Nutzung / usage with said two terms, even for
| F/LOSS)
| TheJoeMan wrote:
| 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/
|
| This is an especially hot topic in the EU in medical device
| regulations: https://www.bsigroup.com/en-GB/insights-and-
| media/insights/b...
| looperhacks wrote:
| 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.
| tnorgaard wrote:
| 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=... -
| which is freely available. Examples can be found here:
| 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 wrote:
| > 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": ... }
| daft_pink wrote:
| Nice that they do this since europeans are obsessed with their
| invoices.
| vldszn wrote:
| 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
|
| Btw, if you have any feedback or suggestions please feel free to
| reach out to me :)
___________________________________________________________________
(page generated 2025-12-12 23:00 UTC)