Latest commit ad294a9
Sep 23, 2016
The password reset token is included in the URL emailed to users who request a password reset. When the user clicks the link, they are brought to the password reset form. If instead of completing the form the user clicks a link to another HTTPS resource that may be in the site navigation, then the password reset token will be leaked to that external site via HTTP referer (sic). Taking advantage of this would require an attack to: 1. Control a site that is linked to on the password reset token 2. Capture any HTTP referers that contain the token 3. Use the referer URL to complete the password reset before the user does so themselves. This is a rather involved exploit, but something we should close nonetheless. We address it in this change by requiring that the token be present in the session rather than in the URL before the page is displayed to the user. If the user hits the edit action with a token in the URL, the token will be stored in the session and the user will be redirected to the same URL minus the token. This is a bit more complicated the another change I considered where we simply rotate the token before the form is displayed. While this change is more involved and less localized, it has the advantage of maintaining the side-effect-free `get` (kind of - we do mutate the session).