This module may have an information disclosure vulnerability (determining user uids from usernames). I originally posted this in security.drupal.org and was told that it is not covered by the security policy (so it doesn't need to be fixed in private).

Steps to reproduce:
1. As an anonymous user, go to this URL, with any username at the end: https://HOSTNAME/user?destination=user/profile/USERNAME (substitute HOSTNAME and USERNAME accordingly)
2. Log in as a user who has to change their password. (Log in as a different user than the username that you just provided).
3. When the user sees the page, the UID is disclosed in the URL.

There is a possibility it only affects my site, as I haven't tested this on a vanilla site. I'm attaching a patch that I've used successfully for a while.

--

Per the documentation that was linked in the security.drupal.org thread, "The Drupal Security Team does not consider it a vulnerability that there are ways to determine a registered members username and/or user id value (i.e. the numeric uid)."

Regardless, I'm providing the (one line of code) patch for the following reasons:

  1. In general, I think unnecessary information disclosure is a security hazard and I don't see a reason not to fix this.
  2. I assume that the changing from username to uid is not intentional.
  3. I think that it is a slightly better user experience when fixed.
CommentFileSizeAuthor
#2 password_policy-uid_disclosure_fix-2899745-2.patch578 bytesnullkernel
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nullkernel created an issue. See original summary.

nullkernel’s picture

nullkernel CreditAttribution: nullkernel commented
Status: Active » Needs review
FileSize
password_policy-uid_disclosure_fix-2899745-2.patch578 bytes
shrop’s picture

shrop CreditAttribution: shrop at Mediacurrent commented

I tried to reproduce the steps with a vanilla Drupal 7 site and I see the correct username, not the expected uid in the URL. Not sure if did something wrong though. I was using the uid 1 admin user and a regular authenticated user role account. Tested with both accounts.

Drupal 7.56
Password Policy 7.x-1.x (b70f9b)

I can test again if you have any thoughts on my test results. Thank you!

AohRveTPV’s picture

AohRveTPV CreditAttribution: AohRveTPV commented

Is /user/profile/<username> a built-in path? When I browse there, even logged in, I get "Page not found".

I couldn't reproduce it either. Here's what I did:
1. Started with two pre-existing users, "foo" and "bar".
2. Logged in as uid 1.
3. Checked "Force password change on next login" for user "bar".
4. Logged out.
5. Browsed to http://example.com/user?destination=user/profile/foo.
6. Logged in as user "bar".
7. Was presented with page to change password. Observed "destination=user/profile/foo" still in URL.
8. Changed password, then got "Page not found" for http://example.com/user/profile/foo.

Drupal 7.56
Password Policy 7.x-1.x-dev

Maybe to discover the conditions needed to reproduce this, you could start from a vanilla site and progressively add parts of your affected site until the problem occurs?

If core doesn't provide a way for users to get uids from usernames, and Password Policy makes it possible, I'd agree with you it'd be better if it didn't.

AohRveTPV’s picture

AohRveTPV CreditAttribution: AohRveTPV commented
Status: Needs review » Postponed (maintainer needs more info)
AohRveTPV’s picture

AohRveTPV CreditAttribution: AohRveTPV commented

shrop, did you get an email from the security team for the security issue nullkernel reported? I'm wondering if I missed emails, or if we just weren't notified because the Security Team decided immediately that it could be fixed publicly. (Seems like a change in process?)

AohRveTPV’s picture

AohRveTPV CreditAttribution: AohRveTPV commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Unable to reproduce this. Please re-open if anyone can help to reproduce it.