12/12/2025 at 9:41:48 PM
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.
by tnorgaard
12/13/2025 at 2:59:25 AM
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.
by aleksejs
12/13/2025 at 4:42:37 PM
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.by BaconVonPork
12/13/2025 at 5:47:50 PM
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.by aleksejs
12/13/2025 at 6:16:12 PM
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?
by BaconVonPork
12/13/2025 at 6:22:42 PM
I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.by aleksejs
12/13/2025 at 7:15:24 PM
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.by BaconVonPork
12/13/2025 at 8:00:36 PM
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.by aleksejs
12/13/2025 at 12:02:45 AM
-----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-----
by michaelt
12/13/2025 at 6:41:56 AM
Or use something similar to jwts, you normalize the document, sign the hash, wrap the original document with metadata and include the signature.by isbvhodnvemrwvn
12/12/2025 at 11:20:13 PM
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.
by fpoling
12/13/2025 at 2:52:42 AM
> If one has a reproducible JSON serializerPretty 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?
by baobun
12/13/2025 at 4:00:05 AM
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.
by butvacuum
12/13/2025 at 11:27:15 AM
> XML-DSig isn't great with XPathsOr at all.
> How would you digitally sign a Json document and embed the signature in the document?
Preferrably you wouldn't because that's a really bad idea.
That said, this type of support-every-conceivable-idea design-by-committee systems would be equally bad built on json or anything else. That much is true.
There's probably no silver bullet here. But that is still not an excuse for XML-Sig.
by xorcist
12/12/2025 at 10:50:14 PM
> 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”: … }by vlovich123
12/12/2025 at 11:33:39 PM
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.
by cogman10
12/13/2025 at 12:13:05 AM
dont unzip an untrusted payloadby bsamuels
12/13/2025 at 12:24:28 AM
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.
by cogman10
12/13/2025 at 4:38:46 AM
hello,by boston_clone
12/13/2025 at 4:46:48 PM
Right, so long as step 1 in reading your file isn't "extract everything" you're pretty safe.This specific exploit is one that only exists when you are extracting a zip on windows.
by cogman10
12/13/2025 at 11:59:05 PM
this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.by boston_clone
12/14/2025 at 12:32:43 AM
A curious search reveals that vulnerabilities that do exist are of 2 flavors.1. Standard C memory vulnerabilities
2. Unsafe file traversal while unzipping
The entire second class is avoided in a fixed file format. The first class of vulnerabilities plague everything. A quick look at libxml2 CVEs shows that.
by cogman10
12/14/2025 at 6:51:49 PM
and the zip bombs you mentioned! i keep a dummy SD card with one hehe.but yeah the first class of vulns is why we have advice like don’t run untrusted input, which is not dissimilar to “don’t unzip untrusted payloads”.
by boston_clone