-
Notifications
You must be signed in to change notification settings - Fork 0
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
Still vulnerable with multiple allowed algorithms #1
Comments
The first example in that example is actually a dud created in haste when trying to understand the full impact of the finding, and we need to correct it because it's confusing people. If you are permitting both algorithms, explicitly, in the same call, then you've deliberately made the choice to permit algorithm confusion. You can permit If your argument is, "We should prevent that in this wrapper library too," then that's worth considering. |
I definitely think it's worth considering, since I ran into this issue and immediately tried the wrapper after seeing your post as a hotfix, with the impression that it also prevents the problem with multiple allowed algorithms. Or alternatively you might want to state explicitly in the README that this is not covered, since I suspect other people will run into the same issue and may be misled into thinking it will fix the issue. Thanks for your immediate response and making people aware of this vulnerability! |
- We guard against invalid algorithms by partitioning by algorithm first - Fix the JWT::encode() wrapping Thanks @cschomburg for this report
This is fixed in |
Maybe I'm missing something obvious, but I tried your library and it is still vulnerable to type confusion when using multiple allowed algorithms (i.e. your first example in firebase/php-jwt#351).
Furthermore your
JWT::encode
function has two problems:$key
,$keyId
and$head
Consider this test case:
The text was updated successfully, but these errors were encountered: