←back to thread

Security issues with electronic invoices

(invoice.secvuln.info)
91 points todsacerdoti | 5 comments | 12 Dec 25 20:28 UTC | HN request time: 1.091s | source
Show context
tnorgaard ◴[12 Dec 25 21:41 UTC] No.46249333[source]▶
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.

replies(6): >>46250010 #>>46250248 #>>46250356 #>>46250567 #>>46251591 #>>46253809 #
aleksejs ◴[13 Dec 25 02:59 UTC] No.46251591[source]▶
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.

replies(1): >>46255877 #
BaconVonPork ◴[13 Dec 25 16:42 UTC] No.46255877[source]▶
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.
replies(1): >>46256372 #
1. aleksejs ◴[13 Dec 25 17:47 UTC] No.46256372[source]▶
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.
replies(1): >>46256614 #
2. BaconVonPork ◴[13 Dec 25 18:16 UTC] No.46256614[source]▶
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?

replies(1): >>46256667 #
3. aleksejs ◴[13 Dec 25 18:22 UTC] No.46256667[source]▶
I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.
replies(1): >>46257067 #
4. BaconVonPork ◴[13 Dec 25 19:15 UTC] No.46257067{3}[source]▶
When I look at JSON related crypto, say JWT or WebAuthn, I am (un)comfortable saying the CVE causing complexities are there but repeating and not consolidated on a standard layer.
replies(1): >>46257455 #
5. aleksejs ◴[13 Dec 25 20:00 UTC] No.46257455{4}[source]▶
I'm not sure why you take me for a JSON/JWT fan (I'm happy to agree they've had their own share of implementation bugs), or what that has to do with signature wrapping bugs in XML-DSig, which is what I've been talking about this entire time.