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

n/a

Original report by @David_Rothstein

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David_Rothstein’s picture

Title: Password reset token is never deleted from SESSION after the password is changed » Password reset token is never deleted from the user's session after the password is changed
Priority: Normal » Major
Status: Active » Needs review
FileSize
1.16 KB

Something 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.

trawekp-1’s picture

There 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?

trawekp-1’s picture

Damn... 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.

Status: Needs review » Needs work

The last submitted patch, user-pass-reset-1939132-2.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review

Thanks! 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...

star-szr’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

CNW and tagging for tests. @David_Rothstein, please correct me if I'm wrong.

dcam’s picture

http://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.

dcam’s picture

Issue summary: View changes

Minor edits.

aparnakondala1’s picture

Issue summary: View changes

Issue summary update is expected

aparnakondala1’s picture

Issue summary: View changes

Updated issue summary.

aparnakondala1’s picture

Issue summary: View changes

Updated issue summary.

aparnakondala1’s picture

Issue summary: View changes

Updated issue summary.

Berdir’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests

#2: user-pass-reset-1939132-2.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs tests

The last submitted patch, user-pass-reset-1939132-2.patch, failed testing.

Berdir’s picture

Issue tags: +Novice, +Needs reroll
@@ -225,7 +225,7 @@ public function form(array $form, array &$form_state, EntityInterface $account)
-   * Overrides Drupal\Core\Entity\EntityFormController::submit().
+   * Overrides Drupal\Core\Entity\EntityFormController::validate().

Either don't touch this or switch to {@inheritdoc} too.

@@ -289,4 +289,15 @@ public function validate(array $form, array &$form_state) {
+   * Overrides Drupal\Core\Entity\EntityFormController::submit().

Should be {@inheritdoc} now.

@@ -289,4 +289,15 @@ public function validate(array $form, array &$form_state) {
+    unset($_SESSION['pass_reset_'. $account->uid]);    ¶

Let's use $user and $user->id(), that should fix thos e exceptions.

Also remove the translation spaces.

Tagging as a novice re-roll.

Albert Volkman’s picture

Re-roll

Albert Volkman’s picture

Status: Needs work » Needs review
FileSize
1.1 KB
1002 bytes

Addressing issues raised in #10.

Status: Needs review » Needs work

The last submitted patch, user-pass-reset-1939132-12.patch, failed testing.

Berdir’s picture

That only addressed 50% of my review, still using ->uid and now mixing $account and $user :)

Albert Volkman’s picture

D'oh.

Albert Volkman’s picture

Status: Needs work » Needs review
FileSize
1000 bytes

One more time.

Status: Needs review » Needs work

The last submitted patch, user-pass-reset-1939132-16.patch, failed testing.

lauriii’s picture

Same patch should pass the test with if isset test. Better if we could not run this class on other cases than this specific case.

lauriii’s picture

Status: Needs work » Needs review
lauriii’s picture

Cleaned the spaces away

garphy’s picture

Status: Needs review » Reviewed & tested by the community

patch in #20 applies cleanly and fixes the issues

garphy’s picture

Issue tags: -Needs reroll

reroll no more needed

catch’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/user/lib/Drupal/user/AccountFormController.php
@@ -309,4 +309,17 @@ public function validate(array $form, array &$form_state) {
 }

This 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?

lauriii’s picture

Status: Needs work » Needs review
FileSize
1.28 KB
2.37 KB

Here's a test and fix for the issue

lauriii’s picture

lauriii’s picture

Issue summary: View changes

Updated issue summary.

herom’s picture

patch is still valid, and ready now.
this is a small patch, and reviewed twice already; so, should be easy to commit.

chx’s picture

This 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.

webchick’s picture

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Great catch!

Committed and pushed to 8.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.