Open greg-1-anderson opened 9 years ago
Marking as 'major', as we need to decide on strategy and then update documentation.
Outsider thought*: Can they be added to the $_SERVER['PRESSFLOW_SETTINGS']
variable based on the domains configured in the dashboard? This way I don't have that "oh shoot" moment as I'm trying to take a site live where I realize I need to do another deployment to my live environment, just to update my settings.php file.
if (isset($_SERVER['PRESSFLOW_SETTINGS'])) {
$pressflow_settings = json_decode($_SERVER['PRESSFLOW_SETTINGS'], TRUE);
foreach ($pressflow_settings as $key => $value) {
// One level of depth should be enough for $conf and $database.
if ($key == 'conf') {
foreach($value as $conf_key => $conf_value) {
$conf[$conf_key] = $conf_value;
}
}
elseif ($key == 'databases') {
// Protect default configuration but allow the specification of
// additional databases. Also, allows fun things with 'prefix' if they
// want to try multisite.
if (!isset($databases) || !is_array($databases)) {
$databases = array();
}
$databases = array_replace_recursive($databases, $value);
}
elseif ($key == 'trusted_hosts') {
foreach ($value as $trusted_host) {
$settings['trusted_host_patterns'][] = $trusted_host;
}
}
else {
$$key = $value;
}
}
}
*As an outsider, I'm not sure of the complexity introduced by adding these values to a global variable given Pantheon's existing architecture. Possibly the docs listing should be MVP for D8 support on Pantheon and this can be added after the fact as a future enhancement (depending on complexity to implement)?
That is an excellent suggestion, @bthompson-mindgrub. I'll look into it on Monday; I think it should be possible.
So, this attack actually is not possible on the Pantheon platform, so an alternative solution here would be to simply remove the warning from the status report page when the site is running on Pantheon (e.g. via a hook in the Pantheon API module)
Downgrading the status of this issue; this is not actually an attack vector, it merely results in an incorrect warning on the status page. We could potentially solve this by altering the status output to "unnecessary on the Pantheon platform", or something of that nature.
There is no real effect on the platform here; downgrading further to "enhancement", since we would just like to improve the firm message that is shown on the status page, so folks know that this isn't actually a problem on Pantheon.
Protecting against HTTP HOST Header attacks explains how to configure your Drupal site so that it cannot be attacked with a number of common social-engineering-style exploits.
Until this is set up, there will be an error message in the status page.
We could quiet this error by putting something similar to the following in settings.pantheon.php:
IMPACT OF NOT DOING THIS: There will be an error on the user's status page. The user must follow the appropriate instructions to make their site secure; then the error will go away. If the user never follows the instructions & launches their site, then their live site will be vulnerable.
IMPACT OF DOING THIS There will be no error on the user's status page. The user's site will be secure. When the user tries to launch their new site on a custom domain, they will discover that their site is inaccessible until they follow the appropriate instructions.
I recommend securing Drupal 8 sites on the above Pantheon domains, and update the DNS configuration instructions to tell the user how to make their site accessible on Pantheon. It is also a viable plan to leave their site unsecured, and update the DNS configuration instructions to tell the user how to make their site secure.