-
Notifications
You must be signed in to change notification settings - Fork 63
Add payload hash to signer JWT claims #356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…he source" This reverts commit 58c6117.
| The token **must include** the following claims: | ||
| - `exp` (integer): Expiration timestamp | ||
| - `module` (string): The ID of the module making the request, which must match a module ID in the Commit-Boost configuration file. | ||
| - `payload_hash` (string): The Keccak-256 hash of the JSON-encoded request body, with optional `0x` prefix. This is required to prevent JWT replay attacks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Json is not an ideal serialization format to hash, let's use ssz with the nonce and object root. As an optimization, we could re use that root directly when providing the signature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but note that this isn't exclusive to signing requests - any request made to the server with a body (e.g., any request that uses POST) needs to do this, which means we need to define SSZ types for every request and have the user conform to those.
Co-authored-by: ltitanb <[email protected]>
Co-authored-by: ltitanb <[email protected]>
This is part 2 of the update on CBST2-01, following #354 and #353. This solves one of the issues found within the audit by making all of the routes with a request body (e.g., the
POSTroutes) encode the Keccak256 hash of the payload body into the JWT claims for the request's auth header. Doing so means JWTs can't be intercepted and reused for unrelated requests, such as for signing different things other than what the original request was for. This affects all routes, including the new/revoke_jwtand/reloadones.