That makes sense in principle but is maybe not particularly actionable or helpful guidance. The need to do some JSON parsing/processing prior to signature verification is kinda inherent to JWS itself. At a minimum the algorithm is in the header. And as you note, a key id or similar might also be in the header and with JWT the issuer is in the payload. In the absence of some out-of-band information or context known, which isn't always the case, some processing has to happen in order to identify the algorithm and key to use to check the signature. For better or worse that's how JWS and JWT work (and I know many have argued it's for the worse but I want to avoid that rabbit hole for now) and SD-JWT builds directly on JWS/JWT so inherits its benefits and flaws.
Do you think there is some useful guidance that could be given at the SD-JWT layer that is still acknowledging of that reality? The SD-JWT verification steps do strongly suggest/imply that the hash check be done before decoding or parsing a Disclosure. Perhaps that could be made more explicit? But that's just one area that JSON parsing happens. On Thu, Oct 12, 2023 at 5:01 PM Orie Steele <orie@transmute.industries> wrote: > hello, > > A recent thread on the JOSE mailing list reminded me of how parsing JSON > strings when not required can lead to scenarios where an attacker can > exploit a vulnerable json parser, possibly before verification occurs... as > tokens can sometimes be the first untrusted user input processed by > systems, this can be very bad. > > The word "parse" does not occur once in > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05 > > And yet, there are instances of "JSON-encoded", which presumes "JSON > decoding", and through implementation experience, I am aware that it is > possible to decode and parse SD-JWTs and their disclosures without > performing any verification of hashes or digital signatures. > > I think it would be wise to add a comment to security considerations > stating something to the effect of: > > In general UTF-8 json strings should not be *parsed* until after a > signature verification or a hash match has been confirmed, in the case that > implementations parse strings that have not yet been authenticated either > by public key signature verification or comparison of a hashed value to > strings that have been verified by a public key, it's possible that a > malicious issuer, or holder might exploit a verifier that relies on a > vulnerable parser. > > There is this section of discovering issuer keys: > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-issuer-signature-key-distri > > My experience tells me that if the issuer has multiple keys, the verifier > is often likely to employ one of these 2 strategies to find the correct key: > > 1. try all the keys they know for the issuer > 2. try a specific key with a specific key id, possibly after parsing the > protected header to obtain the key id. > > In the case that the parsing library is vulnerable, the attacker can craft > a protected header that exploits the verifier prior to signature > verification. > > Apologies if this has already been discussed. > > Regards, > > OS > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
