Closed aiuoe closed 8 months ago
Unless I'm missing something, this isn't a bug: base64 is known to have malleable padding, and any padded base64 message can have up to 16 valid padding permutations.
A base64 decoder can reject these padding permutations, but there isn't much of a point. I don't believe Python's built-in base64decode
even supports checking this, so for pyjwt
to do it would require some additional (error-prone) checking.
(I wrote a tool for automatically generating base64 padding permutations a few years ago: https://blog.yossarian.net/2020/02/03/Finding-treacherous-encoding-permutations-with-baseperm, but I don't think JWT decoding itself is a scenario where this matters.)
This is not like tampering the token. If you can modify the token's payload content without the signature violation check failing, that's another story. If the Base64 decodes to a valid JSON and the JSON is a valid token, I don't see any issue. It is possible to add elements to the header section of the token without the checks failing, as the header is not part of the contents used to create the signature. And that is OK, maybe even useful for some kind of hack, as long as the information included does not require being secured.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Summary.
Expected Result
What you expected.
Actual Result
you can see the last number changed 4 to 5 and work decode What happened instead.
Reproduction Steps
System Information
This command is only available on PyJWT v1.6.3 and greater. Otherwise, please provide some basic information about your system.