Updated: Comment comment #5
Problem/Motivation
If you use the password reset link in Drupal 8, you can reset your password without typing in the previous one (by design).
However, if after changing your password, you reload the edit form again (with the password reset token still in the URL) you can change it again, still without ever typing in the previous one.
You're not supposed to be able to do this. In Drupal 7, you can see in user_profile_form_submit() that there is code to unset the variable in the user's session once the password is changed the first time. This code is gone in Drupal 8.
A little work with git bisect suggests that what probably happened is that first the code got accidentally broken, and then someone else (noticing that it no longer did anything) removed it...
Proposed resolution
Patch application proposed:- Please check https://drupal.org/node/1939132#comment-7162008
Remaining tasks
This patch surely removes 'pass_reset_UID' from session after submit but the problem is when you don't submit the form and go somewhere else.
So consider entering url received in pass reset mail. Then click the button to go to edit form. Then move to different page without submitting the edit form. The 'pass_reset_UID' variable remains in session now.
User interface changes
n/a
Related Issues
n/a
Original report by @David_Rothstein
Comment | File | Size | Author |
---|---|---|---|
#25 | user-pass-reset-1939132-26-tests.patch | 1.86 KB | lauriii |
#25 | user-pass-reset-1939132-26-complete.patch | 2.95 KB | lauriii |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedSomething like the attached patch fixes it. Needs tests, though.
I'm also bumping the priority to major, since it seems like this could be a security regression in some (limited) ways? For example, if you get your hands on an old, expired password reset link for a particular user and then manage to come across a computer where the user is logged in, you can use that information to change their password without authorization.
That does seem like a pretty limited issue to me, but I'm not sure of all the implications either so I'm going with "major" for now.
Comment #2
trawekp-1 CreditAttribution: trawekp-1 commentedThere is still a bug with this. This patch surely removes 'pass_reset_UID' from session after submit but the problem is when you don't submit the form and go somewhere else.
So consider entering url received in pass reset mail. Then click the button to go to edit form. Then move to different page without submitting the edit form. The 'pass_reset_UID' variable remains in session now.
Do you have any idea how to protect from such thing?
Comment #3
trawekp-1 CreditAttribution: trawekp-1 commentedDamn... forget about the patch. It was my testing that shouldn't go here... Your patch is definitely right, mine is not. I don't know how to remove it.
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedThanks! No need to remove the patch; you can just set the issue back to "needs review" and the testbot should be smart enough not to test it again.
So as for the problem you raised, hm, I believe Drupal 7 keeps it in the session in that case too. I think the intention there might have been that if you submit the form once but don't change your password you still have an opportunity to do it again (after all, by definition someone using this link in the first place doesn't know their current password so will need to change it at some point). So if we remove that then people could get stuck after submitting the form and have to generate a new password reset link again, which is annoying although not the end of the world.
I guess it means in general that we can't guarantee the session variable will go away in any particular amount of time, though. I think we should still fix this issue, but perhaps the priority could be lowered after all...
Comment #6
star-szrCNW and tagging for tests. @David_Rothstein, please correct me if I'm wrong.
Comment #7
dcam CreditAttribution: dcam commentedhttp://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.
The summary may need to be updated with information from comments.
Comment #7.0
dcam CreditAttribution: dcam commentedMinor edits.
Comment #7.1
aparnakondala1 CreditAttribution: aparnakondala1 commentedIssue summary update is expected
Comment #7.2
aparnakondala1 CreditAttribution: aparnakondala1 commentedUpdated issue summary.
Comment #7.3
aparnakondala1 CreditAttribution: aparnakondala1 commentedUpdated issue summary.
Comment #7.4
aparnakondala1 CreditAttribution: aparnakondala1 commentedUpdated issue summary.
Comment #8
Berdir#2: user-pass-reset-1939132-2.patch queued for re-testing.
Comment #10
BerdirEither don't touch this or switch to {@inheritdoc} too.
Should be {@inheritdoc} now.
Let's use $user and $user->id(), that should fix thos e exceptions.
Also remove the translation spaces.
Tagging as a novice re-roll.
Comment #11
Albert Volkman CreditAttribution: Albert Volkman commentedRe-roll
Comment #12
Albert Volkman CreditAttribution: Albert Volkman commentedAddressing issues raised in #10.
Comment #14
BerdirThat only addressed 50% of my review, still using ->uid and now mixing $account and $user :)
Comment #15
Albert Volkman CreditAttribution: Albert Volkman commentedD'oh.
Comment #16
Albert Volkman CreditAttribution: Albert Volkman commentedOne more time.
Comment #18
lauriiiSame patch should pass the test with if isset test. Better if we could not run this class on other cases than this specific case.
Comment #19
lauriiiComment #20
lauriiiCleaned the spaces away
Comment #21
garphy CreditAttribution: garphy commentedpatch in #20 applies cleanly and fixes the issues
Comment #22
garphy CreditAttribution: garphy commentedreroll no more needed
Comment #23
catchThis should be 'set' rather than setted. There's trailing whitespace after reset, and it's missing a space between if (isset(
Also I think we could add a test for this?
Comment #24
lauriiiHere's a test and fix for the issue
Comment #25
lauriiiThis one should pass..
Comment #25.0
lauriiiUpdated issue summary.
Comment #26
herom CreditAttribution: herom commentedpatch is still valid, and ready now.
this is a small patch, and reviewed twice already; so, should be easy to commit.
Comment #27
chx CreditAttribution: chx commentedThis is not pertaining to this issue but someone could file a followup to investigate the removal of the user id from the session key that seems like totally unnecessary cos the SESSION is always bound to a specific user anyways.
Comment #28
webchick25: user-pass-reset-1939132-26-complete.patch queued for re-testing.
Comment #29
webchickGreat catch!
Committed and pushed to 8.x. Thanks!