A fatally flawed post that dooms it to the category of SEO rather than what should be useful information. I did especially like:
> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.
The flaw?
There's nothing here not already well known, so this isn't an insightful piece for those already well versed. Therefore, this is a piece written for those that aren't so practiced, for the sake of discussion: junior dev or devops, or non-security devs.
The content itself is a good discussion, and digestible (lol).
But, as a piece that junior folks are expected to get a takeaway from, the introduction is a disaster:
> This post is mostly about authenticating consumers to an API.
ie, not service-to-service auth.
> Unless you have a good reason why you need an (asymmetric) signature, you want a MAC.
A MAC/HMAC requires the signer and all verifiers to have the key. As stated just prior, this is about "frontend" signing. A novice reader might not realize they have to guard the key very well, and might even send it to the client browser. "Unless you have a good reason" is not a sufficiently strong warning for a post that is written as an instructable, more or less.
More architectural introduction (bonus with diagrams) is required. As is, this post is a footgun.
Not sure why you are downvoted, about 10% of the article addresses it's headline and I frankly do not get the point either. The proposed solution is in the first numbered list and between that and the conclusion list is a bunch of prose on non-JSON payload.
The only slightly JSON related content in there is a constructed scenario for 'in-band' signatures (the regex thing) which can just as well be achieved by a bit of string processing. Any JSON object will start with {, end with } and have some more information between it. Replacing the initial curly brace with '{"hmac": "foo",' gives you a valid JSON document. You can remove that easily before parsing and place no restrictions on the object's keys. You can handle edge cases like JSON literals or arrays by wrapping the whole thing in {"hmac": "foo", "payload": yourstring} if you feel like it.
> Not sure why you are downvoted, about 10% of the article addresses it's headline and I frankly do not get the point either. The proposed solution is in the first numbered list and between that and the conclusion list is a bunch of prose on non-JSON payload.
The proposed solution is not in the numbered list. The numbered list describes how to sign a JSON blob from the outside. The rest of the doucment describes what you do if that's not an option, and you need to sign the blob in-line. The very next paragraph after said numbered list describes how to do that.
Ah! So you're saying I should say "Full disclosure" and not "Disclaimer"? (Or nothing at all, as I do here, I suppose :-)) Yes, you're absolutely right and I'll try to do better in the future :)
'Disclosure' is something journalists use to point out a potential external conflict/relationship the reader might unaware of. But you don't need it to point out authorship either. You're really saying 'I want you to be aware I wrote the thing we are discussing' not 'Please don't think I'm sockpuppetting for myself'.
This is a bit like an even more persnickety version 'nation state' in that the trivial fix is just dropping the pointless ceremony.
> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.
The flaw?
There's nothing here not already well known, so this isn't an insightful piece for those already well versed. Therefore, this is a piece written for those that aren't so practiced, for the sake of discussion: junior dev or devops, or non-security devs.
The content itself is a good discussion, and digestible (lol).
But, as a piece that junior folks are expected to get a takeaway from, the introduction is a disaster:
> This post is mostly about authenticating consumers to an API.
ie, not service-to-service auth.
> Unless you have a good reason why you need an (asymmetric) signature, you want a MAC.
A MAC/HMAC requires the signer and all verifiers to have the key. As stated just prior, this is about "frontend" signing. A novice reader might not realize they have to guard the key very well, and might even send it to the client browser. "Unless you have a good reason" is not a sufficiently strong warning for a post that is written as an instructable, more or less.
More architectural introduction (bonus with diagrams) is required. As is, this post is a footgun.