Closed mikipro-matthew closed 2 years ago
Hi,
thank you for raising this issue. I'm no longer maintaining this library, but @anx-hnezbeda is as far as I know :) Anyway, as I am the original author of the linked code I'd like to give my 2 cents ;)
Basically you are correct, the issue is mitigated as we create a new token in the database which is related to the user, and not just the e-mail address. Sending the token (via e-mail, text message, whatever other protocol the dev wants to use) is not handled by the library itself, but via whatever implementation the dev decides to use when listening to the reset_password_token_created
signal.
Hi, what's the status on this one? It seems important... Thx!
Hi! Sorry for the delay. The just released version 1.2.1 fixes the issue.
Hi,
After CVE-2019-19844 was announced I had a look through our internal Django project and dependencies to check it wasn't affected and wanted to make sure there weren't any attack angles.
Here is the potential misbehaving line in this project https://github.com/anexia-it/django-rest-passwordreset/blob/d6d46fcc3dd54f46ca60957bdb21cade563eeac5/django_rest_passwordreset/views.py#L147 - a database search with __iexact which can match with a different address under the conditions in the CVE.
It seems to be mitigated by https://github.com/anexia-it/django-rest-passwordreset/blob/d6d46fcc3dd54f46ca60957bdb21cade563eeac5/django_rest_passwordreset/views.py#L180 as the destination email is fetched from the DB and so the token is sent to the attacked user's actual email address.
To completely resolve the issues described in the CVE you'll need to do a _unicode_ci_compare after the data is returned from the DB to filter out the users that shouldn't have been matched by __iexact.
Let me know if you want me to try to write a patch for this.