WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 2 months ago

#52003 closed defect (bug) (fixed)

Undefined index: PHP_AUTH_PW /wp-includes/user.php on line 469

Reported by: MadtownLems Owned by: TimothyBlynJacobs
Milestone: 5.6.1 Priority: normal
Severity: normal Version: 5.6
Component: Application Passwords Keywords: good-first-bug has-patch has-unit-tests fixed-major
Focuses: Cc:

Description (last modified by SergeyBiryukov)

wp_validate_application_password only checks for the existence of $_SERVER['PHP_AUTH_USER'] before calling wp_authenticate_application_password with both $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'].

In our environment (using Shibboleth-powered Single Sign-on), $_SERVER['PHP_AUTH_USER'] is already set, but $_SERVER['PHP_AUTH_PW'] is not defined.

I believe that this section:

// Check that we're trying to authenticate
if ( ! isset( $_SERVER['PHP_AUTH_USER'] ) ) {
	return $input_user;
}

should likely be extended to confirm the presence of both variables before calling wp_authenticate_application_password.

(Of course, I'm also now worried about what other problems we'll run into using PHP_AUTH_USER the way we are, but that's for another day!)

Attachments (2)

52003.diff (516 bytes) - added by MadtownLems 4 months ago.
Patch of user.php that confirms both variables are set before moving forward with application password authentication
52003.patch (610 bytes) - added by engahmeds3ed 4 months ago.
Simply use one isset with two arguments

Download all attachments as: .zip

Change History (15)

#1 @SergeyBiryukov
4 months ago

  • Description modified (diff)

#2 @TimothyBlynJacobs
4 months ago

Thanks for the ticket @MadtownLems!

To clarify, are you manually setting the $_SERVER['PHP_AUTH_USER'] variable in your site?

#3 @MadtownLems
4 months ago

To clarify, are you manually setting the PHP_AUTH_USER variable in your site?

I apologize in advance for not being an expert in this area, and I'll do the best to explain.

Our WordPress installation itself isn't specifically doing anything with PHP_AUTH_USER. Rather, our webserver is a Shibboleth Service Provider and interacts with our University's Identity Provider to authenticate users. (Our WordPress installation then takes that data and uses it to associate the person with a WordPress user account.)

I have confirmed that PHP_AUTH_USER gets set whenever I try to visit a protected directory that is not related to WordPress at all.

I have no idea how common Shibboleth is, so here is a link for reference in case it's helpful:

https://www.shibboleth.net/index/basic/

Always happy to answer any more questions, help look into this more, or test things!

#4 @TimothyBlynJacobs
4 months ago

  • Milestone changed from Awaiting Review to 5.6.1

Thanks @MadtownLems! I'm not very familiar with shibboleth either. I'm wondering if we may want to run even if PHP_AUTH_PW isn't set, but set it to an empty string.

But in my testing at least, even if a password is omitted when doing Basic Auth PHP_AUTH_PW is still set, but to an empty string. Does anyone know if that is always the case when a password is omitted? If so, then I would agree we can just also check for PHP_AUTH_PW being set.

#5 @TimothyBlynJacobs
4 months ago

Chatting with @richard.tape and doing some research it seems expected that shibboleth wouldn't populate PHP_AUTH_PW. I found this semi related issue https://github.com/symfony/symfony/issues/17345 and https://shibboleth.1660669.n2.nabble.com/Populate-PHP-AUTH-PW-var-td6185938.html

So now the question is just if PHP_AUTH_PW would be omitted by valid usages of Basic auth on some server setups.

#6 @johnbillion
4 months ago

If this is allowed it ought to be fixed in places where PHP_AUTH_PW is passed through, for example the site health Ajax checks and the plugin and theme editor syntax checks.

#7 @TimothyBlynJacobs
4 months ago

  • Keywords good-first-bug needs-patch added

@johnbillion It looks like the rest of Core is already also looking for PHP_AUTH_PW. So I think @MadtownLems your proposed solution makes sense. Do you want to take a go at making a patch for it?

#8 @MadtownLems
4 months ago

Gladly. It's been almost a decade since my last actual patch, but I'm not gonna find an easier one to shake the rust off with!

I'll put something together soon.

@MadtownLems
4 months ago

Patch of user.php that confirms both variables are set before moving forward with application password authentication

@engahmeds3ed
4 months ago

Simply use one isset with two arguments

#9 @hellofromTonya
4 months ago

  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in PR #847 on WordPress/wordpress-develop by TimothyBJacobs.


3 months ago

  • Keywords has-unit-tests added

#11 @TimothyBlynJacobs
3 months ago

  • Owner set to TimothyBlynJacobs
  • Resolution set to fixed
  • Status changed from new to closed

In 49919:

App Passwords: Only attempt auth if the username and password are set.

Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the PHP_AUTH_USER field.

Props MadtownLems, johnbillion, richard.tape, engahmeds3ed.
Fixes #52003.

#12 @TimothyBlynJacobs
3 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backport.

#13 @whyisjake
2 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 50045:

App Passwords: Only attempt auth if the username and password are set.

Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the PHP_AUTH_USER field.

This brings the changes from [49919] to the 5.6 branch.

Props MadtownLems, johnbillion, richard.tape, engahmeds3ed, TimothyBlynJacobs.

Fixes #52003.

Note: See TracTickets for help on using tickets.