shreemaan-abhishek opened a new pull request, #13518:
URL: https://github.com/apache/apisix/pull/13518
### Description
`jwt-auth`'s custom JWT parser (`apisix/plugins/jwt-auth/parser.lua`)
replaced `resty.jwt` verification with per-algorithm verifiers.
`verify_signature` looked up the verifier and passed the decoded signature
without guarding either path:
```lua
function _M.verify_signature(self, key)
return alg_verify[self.header.alg](self.raw_header .. "." ..
self.raw_payload, base64_decode(self.signature), key)
end
```
The per-algorithm verifiers `assert` on signature length and key validity,
and `base64_decode` returns `nil` for an invalid base64url signature. So a
token with a **wrong-length signature** (`assert(#signature == 64, "Signature
must be 64 bytes.")`) or a **non-base64url signature** (`#nil` -> "attempt to
get length of a nil value") makes the verifier raise a Lua error. Since the
caller invokes `verify_signature` without a guard, the error propagates and the
request returns **500 instead of 401** for any route protected by `jwt-auth`.
An unauthenticated client that knows a valid consumer key can repeatedly
trigger these internal errors and error-log noise.
This makes `verify_signature` defensive: guard the algorithm lookup and the
base64url decode, and run the verifier under `pcall` so a malformed token is
cleanly rejected as an invalid signature instead of crashing the request.
#### Which issue(s) this PR fixes:
N/A (reported via a private security scan)
### Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [ ] I have updated the documentation to reflect this change (no
user-facing behavior or config change; internal robustness fix only)
- [x] I have verified that this change is backward compatible
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
