-
Notifications
You must be signed in to change notification settings - Fork 662
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
Reported vulnerability in 5.3.1 #805
Comments
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 create inactive userinactive_user_id = User.objects.create_user('testuser', 'test@example.com', 'testPassw0rd!', is_active=False).id django application programmer generates token for the inactive userAccessToken.for_user(User.objects.get(id=inactive_user_id)) # error should be raised since user is inactive django application verifying user tokenAccessToken.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.is_active: 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. |
Is is possible to silence safety error then? |
Safety vulnerability scanner reports the following vulnerability in the latest version of this package:
The text was updated successfully, but these errors were encountered: