#34654: Post-normalization performed on the Username field leading to the
bypass of
the whitespace stripping
------------------------------+--------------------------------------------
Reporter: Sim4n6 | Owner: George Kussumoto
Type: Bug | Status: assigned
Component: contrib.auth | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------------
Comment (by George Kussumoto):
Here are some ideas to discuss:
- To the main point of bypassing white space removal: while this is true
for the `UsernameField`, most forms using this field also have another
validation in the model level, such as `UnicodeUsernameValidator` and
`EmailValidator`. These validators run on post-normalized values, so
symbols like `BRAILLE PATTERN BLANK` or white space (regardless of
position) will raise errors.
- The `AuthenticationForm` might not invalidate such inputs, but to
successfully exploit this, one should have bypassed the creation form
first (I think). I'm not a security expert, but maybe there's an
additional condition of using non-unique usernames.
- The case for the password reset is already addressed in
https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
- When using custom user models things are different, the application code
should include the appropriate validators. Depending on the
implementation, the normalization steps too.
- At first, I thought about adding `UnicodeUsernameValidator` to the
`UsernameField`. It was promising, all tests passed. Then I realized it
not only breaks compatibility, but we shouldn't make this assumption on
the username since the validator is particular about what it accepts,
compromising the flexibility to set `USERNAME_FIELD` in custom models. For
example, `UnicodeUsernameValidator` is stricter than `EmailValidator` (at
least at first glance).
- Another possibility was to add the validator in the form definition
instead of the form field (since it's expected some customization when
using custom models). Possible candidates were `UserCreationForm` and
`UserChangeForm`
([https://docs.djangoproject.com/en/dev/topics/auth/customizing/#custom-
users-and-the-built-in-auth-forms custom-users-and-built-in-auth-forms
doc]) since they are more tied to the default user model. But this is
already accomplished by having the validator in the model.
- As mentioned before in the comments, re-running `.strip()` after
normalization or comparing string length doesn't seem to address the
problem reported.
So far, I don't have a conclusion, but I lean lightly on the side that no
code changes are required. I wanted to share my thoughts and hear others.
I don't have a security background so I might have overlooked/simplified
things a bit. Please keep that in mind.
--
Ticket URL: <https://code.djangoproject.com/ticket/34654#comment:13>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701909ea86f13-162896ca-a5b9-4a9f-bffe-b2bc2859c13b-000000%40eu-central-1.amazonses.com.
