Skip to content
This repository has been archived by the owner on Aug 8, 2024. It is now read-only.

Protect against HTTP HOST Header attacks by default #79

Open
greg-1-anderson opened this issue Sep 18, 2015 · 6 comments
Open

Protect against HTTP HOST Header attacks by default #79

greg-1-anderson opened this issue Sep 18, 2015 · 6 comments

Comments

@greg-1-anderson
Copy link
Member

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:

$settings['trusted_host_patterns'][] = '.getpantheon.com$';
$settings['trusted_host_patterns'][] = '.pantheon.io$';
$settings['trusted_host_patterns'][] = '.panth.io$';

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.

@greg-1-anderson
Copy link
Member Author

Marking as 'major', as we need to decide on strategy and then update documentation.

@rvtraveller
Copy link

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

@greg-1-anderson
Copy link
Member Author

That is an excellent suggestion, @bthompson-mindgrub. I'll look into it on Monday; I think it should be possible.

@greg-1-anderson
Copy link
Member Author

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)

@greg-1-anderson
Copy link
Member Author

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.

@greg-1-anderson
Copy link
Member Author

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.

greg-1-anderson added a commit that referenced this issue Jun 14, 2018
…low all domains, since the attack this feature prevents cannot be employed against Pantheon sites. By Christopher Matthews.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants