#27518: HTTP Referer leaks password reset link
----------------------------------+--------------------------------------
Reporter: Romain Garrigues | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: 1.10
Severity: Normal | Resolution:
Keywords: password reset | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------
Description changed by Romain Garrigues:
Old description:
> Hi security team!
>
> I read an article titled "Is Your Site Leaking Password Reset Links?"
> (https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links)
> and I just realised that by using classic Django password_reset_confirm
> view, my reset password link was effectively sent to other websites in
> the HTTP Referer header.
>
> The use case is this one:
> - A customer receives a link to be able to reset his password on a Django
> powered website,
> - He clicks on this link, arrives on a page with the password change
> form, and if on that page, there are calls to external resources, like
> cdn, the whole url will be sent in the HTTP header of the request,
> - If he directly resets this password, no issue, the token is no more
> valid,
> - If for any reason he doesn't reset his password straight away, some
> external website could get this url and change the password in behalf of
> the user.
>
> Removing the HTTP Referer header
> (http://stackoverflow.com/questions/6817595/remove-http-referer) can be a
> solution, but wouldn't it interesting to implement some checks in Django
> password_reset_confirm view?
>
> After some discussions with the security team, it has been classified as
> not really serious and could be discussed in public.
> I will propose 2 approaches to solve it, with their respective issues.
New description:
Hi!
I read an article titled "Is Your Site Leaking Password Reset Links?"
(https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links)
and I just realised that by using classic Django password_reset_confirm
view, my reset password link was effectively sent to other websites in the
HTTP Referer header.
The use case is this one:
- A customer receives a link to be able to reset his password on a Django
powered website,
- He clicks on this link, arrives on a page with the password change form,
and if on that page, there are calls to external resources, like cdn, the
whole url will be sent in the HTTP header of the request,
- If he directly resets this password, no issue, the token is no more
valid,
- If for any reason he doesn't reset his password straight away, some
external website could get this url and change the password in behalf of
the user.
Removing the HTTP Referer header
(http://stackoverflow.com/questions/6817595/remove-http-referer) can be a
solution, but wouldn't it interesting to implement some checks in Django
password_reset_confirm view?
After some discussions with the security team, it has been classified as
not really serious and could be discussed in public.
I will propose 2 approaches to solve it, with their respective issues.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27518#comment:1>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.f4e1b7640c62a5328e8d2c2c98bd9e81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
