> restrict header lengths (e.g. 256 bytes) Way too small; there can be cert chains in the header (“x5c”).
> There are a reasonable number of things you can do to limit risk around > unverified headers that are not suitable/feasible for payloads. So perhaps a solution is for a library to offer a peekAtClaims() method that parses the payload under the same restrictions used to parse headers. It either works and the caller can get “iss”; or it fails because the payload didn’t meet the conditions, but it is unlikely to be a JWT with an “iss” in that case so no loss. >> If you can get remote code execution with a malicious payload, but only >> after the signature is verified, you still have a critical bug. > I'm not sure why this was mentioned - I am discussing parsing payloads > _before_ signature verification. If parsing a payload before sig verification causes RCE, surely running the same parsing code on the same payload after verification will cause the same RCE. -- James Manger General From: Les Hazlewood <[email protected]> Date: Friday, 13 October 2023 at 12:11 pm To: Manger, James <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [jose] JWS signature verification and claims payload [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Interpreting an unverified header as a JSON object isn’t any less risky than interpreting an unverified payload as a JSON object in theory. Implementations may have differences (could a WAF check JOSE headers, but not payloads?). I disagree. Remote code execution attacks can embed code in claims, and those claims could be reasonably/significantly larger than a header. Additionally, JSON nesting depth (when excessive can cause stack overflow Denial of Service attacks) can be more easily restricted in a header (e.g. flat or two levels max). You can also more easily restrict header lengths (e.g. 256 bytes). There are a reasonable number of things you can do to limit risk around unverified headers that are not suitable/feasible for payloads. If you can get remote code execution with a malicious payload, but only after the signature is verified, you still have a critical bug. I'm not sure why this was mentioned - I am discussing parsing payloads _before_ signature verification. > And even if the payload is Claims JSON, payloads are often significantly > larger than headers, so they're not the same from a risk perspective. The primary security risk of looking at the payload before verifying a signature is not the type/size issue. The primary risk is API ergonomics: does it make it too easy for a developer to accidentally forget to do the verification? Might they comment-out the verification call while debugging then forget to re-enable it? Sure, that's a primary risk, but not the only risk. I'm addressing other risks that are reasonably expected to be encountered in modern web applications if the JWS signature is not verified first. In any event, it seems as if the JOSE committee either a) didn't address these risks or b) they did internally, and explicitly chose to omit any associated requirements, expecting library/application developers to decide for themselves. I wonder if submitting an errata would lead to anything? My desire was to get confirmation on this list first since presumably the JOSE committee members read it, rather than stir up something more formal/complicated via an errata or supplementary RFC process (yikes). Kind regards, Les
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
