> > 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
