> Is it the consensus of the JOSE RFC committee that parsing a JWS payload > before it is trusted is acceptable?
There isn’t a committee to give you an answer. The consensus is the RFCs. It’s clear that “iss” is sometimes needed before verification; and will not always (if ever) be duplicated in the header when it is unencrypted in the payload (eg a JWS). > I ask because, while I appreciate your suggestion, it doesn't address _why_ > parsing any payload before it is verified is acceptable from a security > standpoint and should be supported by JWS libraries. Is it a concession the > RFC committee has discussed? 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?). > Remember, a JWS payload can be anything at all - not just JSON, and even if > JSON, not necessarily Claims. Parsing any stream of bytes well before they > become a Map<String,Object> could potentially enable remote code execution > attacks or other problems. If you can get remote code execution with a malicious payload, but only after the signature is verified, you still have a critical bug. > 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? -- James Manger General
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
