Author: Paul Gilzow

TL;DR – You’re going to need to map your domains to the COOKIE_DOMAIN constant.

We run numerous WordPress networks on campus, almost all of which are set up with multiple independent subdomains (e.g. foo.missouri.edu, bar.missouri.edu, etc.).  Historically, a WordPress network only supported subdomains based off a root domain (e.g. root domain of mysite.com, child sites of foo.mysite.com, bar.mysite.com, etc.). One way to be able to map independent domains in a network was with the WordPress MU Domain Mapping plugin.  We’ve been doing this awhile so this was our standard set up when running a network.

Recently, Aaron Duke asked me why I was still using the MU Domain Mapping plugin when WordPress had integrated domain mapping natively into WordPress as of version 4.5. Short answer: I must have missed that in the changelog for 4.5.  Reading through the documentation, I still wasn’t convinced it would work in our situation (as described above).  I set up a test WordPress subdomain network for an account where I had two domains pointed to the same account on the server.   Following the directions from the docs¹, I set up both sites and added a second user. Added a couple of posts to the main site (foo.missouri.edu) and verified pretty links were working correctly. Good so far.  Went to log into the second site (bar.missouri.edu) and was presented with the “Cookies are blocked” error message.

In looking at the headers, sure enough, WordPress was attempting to set the domain property of the WP Cookie Check cookie to foo.missouri.edu instead of bar.missouri.edu.  I reached out to some WordPress colleagues to try and see if it was something I had missed. The ever lovely Rachel Carden mentioned seeing similar issues if the DOMAIN_CURRENT_SITE constant was set incorrectly.  Charles Fulton suggested manually setting the COOKIE_DOMAIN constant to .missouri.edu.  While this would technically solve the issue, I didn’t want to wildcard the cookie like that as it would allow it to be read by a rogue site on the missouri.edu domain (and trust me, there are rogue sites out there).  Surely there had to be a better way.

Taking Rachel’s and Charles’ suggestions, I started digging into the WordPress core.  Since the problem is with the cookie domain, I started with debugging when and where WordPress sets cookies.  In wp-login.php,  we find that it sets the WP Cookie Check cookie at line 407, using the constant COOKIE_DOMAIN for the domain property.

[php firstline=”407″]setcookie( TEST_COOKIE, ‘WP Cookie check’, 0, COOKIEPATH, COOKIE_DOMAIN, $secure );[/php]

For subdomain multisites, this constant is defined starting at line 78 in the function ms_cookie_constants() in the file ms-default-constants.php.

[php firstline=”49″ highlight=”78″]
function ms_cookie_constants( ) {
$current_network = get_network();

/**
* @since 1.2.0
*/
if ( !defined( ‘COOKIEPATH’ ) )
define( ‘COOKIEPATH’, $current_network->path );

/**
* @since 1.5.0
*/
if ( !defined( ‘SITECOOKIEPATH’ ) )
define( ‘SITECOOKIEPATH’, $current_network->path );

/**
* @since 2.6.0
*/
if ( !defined( ‘ADMIN_COOKIE_PATH’ ) ) {
if ( ! is_subdomain_install() || trim( parse_url( get_option( ‘siteurl’ ), PHP_URL_PATH ), ‘/’ ) ) {
define( ‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH );
} else {
define( ‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH . ‘wp-admin’ );
}
}

/**
* @since 2.0.0
*/
if ( !defined(‘COOKIE_DOMAIN’) && is_subdomain_install() ) {
if ( !empty( $current_network->cookie_domain ) )
define(‘COOKIE_DOMAIN’, ‘.’ . $current_network->cookie_domain);
else
define(‘COOKIE_DOMAIN’, ‘.’ . $current_network->domain);
}
}
[/php]

From there we see that it using the object $current_network for the value used to define the constant.  $current_network is returned from the call to function get_network at line 50.  get_network() is defined on line 1098 of ms-blogs.php and attempts to return an instance of WP_Network based on either a network ID passed into the function or by using the global $current_site.

[php firstline=”1098″]
function get_network( $network = null ) {
global $current_site;
if ( empty( $network ) && isset( $current_site ) ) {
$network = $current_site;
}

if ( $network instanceof WP_Network ) {
$_network = $network;
} elseif ( is_object( $network ) ) {
$_network = new WP_Network( $network );
} else {
$_network = WP_Network::get_instance( $network );
}

if ( ! $_network ) {
return null;
}

/**
* Fires after a network is retrieved.
*
* @since 4.6.0
*
* @param WP_Network $_network Network data.
*/
$_network = apply_filters( ‘get_network’, $_network );

return $_network;
}
[/php]

We know our call to the functions from inside of ms_cookie_constants didn’t include any parameters, so the global $current_site must already contain data. Adding a watch revealed that was in fact already populated by the time get_network was called. Alright, we’ll need to track down when $current_site is initially created: schema.php, ms-settings.php, and ms-load.php.  ms-settings.php and ms-load.php are loaded during a login, and ms-settings.php calls the function ms_load_current_site_and_network() in ms-load.php which is where, FINALLY, we find the first instantiation of $current_site. Wait, why was I trying to track down $current_site?  😀

[php firstline=”283″]
function ms_load_current_site_and_network( $domain, $path, $subdomain = false ) {
global $wpdb, $current_site, $current_blog;

// If the network is defined in wp-list.php, we can simply use that.
if ( defined( ‘DOMAIN_CURRENT_SITE’ ) && defined( ‘PATH_CURRENT_SITE’ ) ) {
$current_site = new stdClass;
$current_site->id = defined( ‘SITE_ID_CURRENT_SITE’ ) ? SITE_ID_CURRENT_SITE : 1;
$current_site->domain = DOMAIN_CURRENT_SITE;
$current_site->path = PATH_CURRENT_SITE;
if ( defined( ‘BLOG_ID_CURRENT_SITE’ ) ) {
$current_site->blog_id = BLOG_ID_CURRENT_SITE;
} elseif ( defined( ‘BLOGID_CURRENT_SITE’ ) ) { // deprecated.
$current_site->blog_id = BLOGID_CURRENT_SITE;
}

if ( 0 === strcasecmp( $current_site->domain, $domain ) && 0 === strcasecmp( $current_site->path, $path ) ) {
$current_blog = get_site_by_path( $domain, $path );
} elseif ( ‘/’ !== $current_site->path && 0 === strcasecmp( $current_site->domain, $domain ) && 0 === stripos( $path, $current_site->path ) ) {
// If the current network has a path and also matches the domain and path of the request,
// we need to look for a site using the first path segment following the network’s path.
$current_blog = get_site_by_path( $domain, $path, 1 + count( explode( ‘/’, trim( $current_site->path, ‘/’ ) ) ) );
} else {
// Otherwise, use the first path segment (as usual).
$current_blog = get_site_by_path( $domain, $path, 1 );
}
[/php]

$current_site is simply a stdClass object where the property domain is set to the constant DOMAIN_CURRENT_SITE.  So now we know that back in the function get_network() in ms-blogs.php uses the value of $current_site for $network and uses it to instantiate a new instance of WP_Network at line 1107.  Now that we know where the information for WP_Network comes from, let’s look to see how it determines the property cookie_domain.  During the __construct method there is a call to the private method _set_cookie_domain(), and look there at line 244.

[php firstline=”230″ highlight=”244″]
/**
* Set the cookie domain based on the network domain if one has
* not been populated.
*
* @todo What if the domain of the network doesn’t match the current site?
*
* @since 4.4.0
* @access private
*/
private function _set_cookie_domain() {
if ( ! empty( $this->cookie_domain ) ) {
return;
}

$this->cookie_domain = $this->domain;
if ( ‘www.’ === substr( $this->cookie_domain, 0, 4 ) ) {
$this->cookie_domain = substr( $this->cookie_domain, 4 );
}
}
[/php]

We finally see that cookie_domain is simply set to the same domain as was defined in the constant DOMAIN_CURRENT_SITE. And it appears that this scenario is a known issue; look at the todo there at line 234.

@todo What if the domain of the network doesn’t match the current site?

So now, circling all the way back to where we started, we can see that in the function ms_cookie_constants() in the file ms-default-constants.php, if COOKIE_DOMAIN isn’t already defined (e.g. in wp-list.php or a plugin), then it will be set to the cookie_domain or the domain properties, which are the exact same thing.  Which means that in order to set the domain property in the cookie to the correct domain in our WordPress network setup, we’re going to need to set it ourselves.

The challenge is we need to set the COOKIE_DOMAIN before wp-settings.php calls the function ms_cookie_constants().  In looking through the WordPress Core Load chart, I can see the only file we have direct access to before wp-settings.php loads is wp-list.php.  I could add our logic into wp-list.php, but I’d rather not place logic in a list file.  In looking through wp-settings.php, both network-activated plugins and must-user plugins are loaded and the action hook muplugins_loaded is fired before ms_cookie_constants is called.  There’s our answer: add the code to a plugin, hook it to the muplugins_loaded action and network-activate it!

The code is simple enough

[php]
Plugin Name: COOKIE_DOMAIN mapper
Plugin URI: https://gilzow.com/
Description: Maps the current domain into COOKIE_DOMAIN in a multisite set up
Author: @gilzow
Version: 0.1
Author URI: https://gilzow.com/
*/

add_action(‘muplugins_loaded’,function(){
if(defined(‘MULTISITE’) && MULTISITE && !defined(‘COOKIE_DOMAIN’) && DOMAIN_CURRENT_SITE !== $_SERVER[‘SERVER_NAME’]){
if(1 === preg_match(‘/^(?:www.)?((?:[A-Za-z0-9_\-]+\.){1,3}[A-Za-z0-9_\-]{2,})$/’,$_SERVER[‘SERVER_NAME’],$aryMatches)){
define(‘COOKIE_DOMAIN’,$aryMatches[1]);
}
}
});
[/php]

If MULTISITE is set to true, COOKIE_DOMAIN isn’t already defined and the SERVER_NAME environmental variable is not equal to the value in DOMAIN_CURRENT_SITE, send it to the regular expression (regex) statement.  In the regex, we start with checking to see if there is a www at the beginning, but we don’t care about it (the ?: indicates to the regex engine to not capture this group).  Then we check to see if there is 1 to 3 groups of 1 to infinity number of A through Z (lower and uppper case), digits, underscores and dashes followed by a period.  Those groups need to be followed a group of characters of at least 2 characters or more of the same A-Z (upper/lower), digits, underscores and dashes.  That whole thing is captured. If there’s a match, place the values matched and captured into the variable $aryMatches. If we have a match, take the capture group (key 1 in the array) and use that value for our COOKIE_DOMAIN constant.

Why the regex instead of just using SERVER_NAME or HTTP_HOST?  Host is from the header sent to us by the client so it can’t be trusted.  And while one would think SERVER_NAME would be safe since it is (supposed to be) an environmental variable, it’s actually determined in part from the HTTP_HOST value.  Now, it’s unlikely someone would be able to inject a value into the Host that would result in an exploit here, but better safe than sorry.  Instead, we’re going to simply make sure that the host name only includes alphanumeric characters, dashes and underscores.  The only thing that one might need to change is the 3 in {1,3}. At three, the domain foo.bar.gilzow.com (fourth-level) would be valid and match, but biz.foo.bar.gilzow.com (fifth-level) would not.  If you need to use fifth-level or more subdomains, you’ll need to adjust that value accordingly.

Having added the plugin, and network activating it, I can now successfully log into the subsite, and in viewing the headers, see that it is setting the domain property on the cookie to the correct domain.  Success!

Having walked through the code, I’m now wondering how anyone using independent domains has been able to get a WordPress subdomain network working correctly without accounting for the cookie domain property?  And given the @todo in the WP_Network class, it appears that this is a known limitation.  Or maybe our environment is unique and we’re the only ones running into this issue?

Hit me up in the WPCampus slack team or over at wordpress.org if you’d like to discuss it.

Note ¹: Our sites are located on a central shared-hosting, load-balanced environment.  Each site is a CNAME of the domain for the hosting environment which is set as the A Record.  So we were unable to follow Step #3 of Multisite Domain Mapping Without a Dedicated IP or Plugin since you’re not supposed to assign a CNAME to another CNAME. In addition, we do not map the subsite domain as a fourth-level subdomain of the main site’s domain.

I know I sound like a broken record, but if you are running WordPress version 4.7.X please make sure you have installed the 4.7.2 update. There are now up to 1.5 million defacements due to the REST API vulnerability, and several monitoring companies are beginning to see Remote Code Execution attempts against the vulnerability.  If for any reason, you are on 4.7.0 or 4.7.1 and are unable to upgrade, or don’t think you can, PLEASE reach out to me. 

 This week’s report: https://docs.google.com/spreadsheets/d/1JaYqIIAclJjIQ3vWOmcLel5Bra0vPrRacVR8tt7H4uA/edit?usp=sharing

Not as many vulnerabilities to report this week (that’s good, right?).  Just four.

20170113 Vulnerable Plugins Report

I would like to mention that one of the security items fixed in version 4.7.1 of WordPress this week isn’t as complete as it initially sounds.

The REST API exposed user data for all users who had authored a post of a public post type. WordPress 4.7.1 limits this to only post types which have specified that they should be shown within the REST API.

As I have mentioned a couple of times, exposing your user data publicly is a bad idea and goes directly against OWASP A6 Sensitive Data Exposure.  From the changelog (quoted above) it sounds like in v4.7 your user data was only exposed if the user had authored a public post, but that’s not correct.  When I first heard about the user endpoints in the REST API, I discovered that all users who were capable of publishing were exposed, even if they had never published anything (and don’t forget: your first admin user is automatically added as the author of the example post when installing WordPress). In the v4.7.1 fix, they’ve changed that to be only post types that are to be shown in the REST API, but don’t forget that the default post type is included automatically.

The above screenshot is from a version 4.7.1 WordPress site that has not had the user endpoints removed. As you can see, the account adamsmel does not have any posts.  In fact, this particular site is brand new and doesn’t have any posts, published or draft, at all.   However, when querying the REST API for users, her account still shows up.

 

 

 

 

 

Now, it’s possible that the change introduced in version 4.7.1 only affects new user accounts that are added after the 4.7.1 update is applied, but that still leaves millions of sites at risk of exposing their usernames.

I love the REST API; I truly do, but considering the amount of information potentially exposed, it has to be done securely.  Until the REST API can be placed behind authentication, then the WordPress core team needs to remove the default post type from automatically being included in the REST API and remove the user endpoints.  Give developers the ability to expose those endpoints if they want, but don’t make it the default for the millions of WordPress installations that will never see a developer.