SimSama
commented
5 months ago Curious reader here myself.
I was reading over the code here and I think the vulnerability is very low (explanation below). I think the framework could be better designed to prevent token generation, I'll look at at forking and testing later this week.
From the CVE
from django.contrib.auth.models import User from rest_framework_simplejwt.tokens import AccessToken
create inactive user
inactive_user_id = User.objects.create_user('testuser', 'test@example.com', 'testPassw0rd!', is_active=False).id
django application programmer generates token for the inactive user
AccessToken.for_user(User.objects.get(id=inactive_user_id)) # error should be raised since user is inactive
django application verifying user token
AccessToken.for_user(User.objects.get(id=inactive_user_id)).verify() # no exception is raised during verification of inactive user token
So the argument here is that you can still create a token manually, and verify the token if user is disabled, however you cannot login with that token. In authenticate module, the get_user function explicitly raises error if user is inactive.
if not user.isactive: raise AuthenticationFailed(("User is inactive"), code="user_inactive")
So you can manually generate all the tokens you want, but you can't login and view sensitive data if user disabled. A setting to disable token generation if user disabled default is a simple ask however.
I haven't explicitly tested, I'll see if I can do that this week.
Marpop
miseas
Safety vulnerability scanner reports the following vulnerability in the latest version of this package: