Настройки доверенного хоста

Эта документация неполная. Получите больше информации.

Защита от атак HTTP HOST Header (не позволяйте вашему сайту думать, что это кто-то другой)

Drupal 7 добавил в ядро новую функцию, которая не предназначена для непосредственного взаимодействия с пользователем, но иногда называется poormanscron. Эта функция запускает периодические задачи сайта Drupal, такие как очистка файлов журналов, отправка электронных писем и очистка кешей. Эта функция в сочетании с динамическим определением «базового URL» (добавлено в Drupal 4.7) может привести к некоторым странным ситуациям. Эта статья представляет собой описание некоторых из этих странных ситуаций, возникающих с обоими модулями или обоими, и того, что вы можете сделать, чтобы предотвратить их. Комментарии ниже предполагают некоторые конфигурации по умолчанию - в конце я расскажу, как отойти от этих настроек по умолчанию, чтобы предотвратить эти проблемы.

Сценарий 1. Получение / отправка электронных писем пользователей, которые предназначены для другого домена

Это поведение довольно легко повторить:

1. Укажите новый домен по IP-адресу существующего сайта - давайте назовем существующий сайт http://www.example.com, а новое имя, указывающее на этот IP-адрес, будет http://other-site.example.org.

2. Посетите URL: http://other-site.example.org/user/password

3. Введите имя пользователя, которое, вероятно, будет использоваться на сайте.

В результате на шаге 2 обнаружение $ base_url считает, что ваш сайт http://other-site.example.org и все токены для электронной почты, например [user: one-time-login-url], которые содержат ссылки на ваш сайт будут изменены для использования http://other-site.example.org в качестве базового URL. Пользователь, получивший это электронное письмо, увидит, что его имя пользователя и электронная почта для example.com теперь каким-то образом используются на http://other-site.example.org, что обычно просто сбивает с толку. Однако из этого могут прийти два плохих сценария:

• В худшем случае это может привести к тому, что они нажмут на ссылку для сброса пароля, которую злой сайт сможет затем использовать для входа на сайт от имени этого пользователя.
• Они могут ввести свое имя пользователя / пароль в http://other-site.example.org - так называемая атака социальной инженерии - которая затем может быть использована на главном сайте.

Сценарий 2. Кэширование записей, содержащих неправильный домен

Аналогичная проблема может возникнуть, когда пользователь использует неправильный домен для выполнения запроса, и это происходит с запросом, который заполняет запись в кэше с динамическими, полностью определенными доменами в нем. Последующие посещения, которые извлекают информацию из этого кэша, получат неправильное доменное имя. Страничный кеш ядра Drupal использует домен как часть идентификатора кеша, предотвращая эту проблему, но другие механизмы кэширования могут быть не столь устойчивы к этой проблеме.

Сценарий 3: Почтовые уведомления, содержащие неправильный домен

Еще одна проблема может возникнуть на сайтах, которые используют модули, отправляющие электронную почту во время работы cron. Этот сценарий требует poormanscron с динамическим определением base_url. Если пользователь случайно запускает poormanscron, когда в очереди появляются уведомления при посещении неправильного доменного имени, тогда уведомления будут отправляться с этим неправильным доменом. Пользователи будут очень смущены тем, почему почта, которую они ожидают получить с адреса электронной почты на example.com, содержит ссылки на домен http://other-site.example.org.

Решения для запутанного опыта с динамическим обнаружением Drupal base_url

Существует как минимум четыре возможных решения этой проблемы, хотя не все они необходимы для предотвращения возникновения проблемы. Вы должны выбрать и выбрать в соответствии с вашей средой.

1. Вы можете установить определенный домен как ваш $base_url in sites/default/settings.php. Хотя динамическое обнаружение может быть удобной функцией, оно также может вызвать проблемы. Один из способов остановить это - установить постоянное значение.

2. Используйте определенный sites/example.com/settings.php и пусть динамически обнаруживается $base_url - это означает, что Drupal отвечает всем поддоменам example.com, что может быть или не быть преимуществом.

3. Настройте свой веб-сервер таким образом, чтобы страница по умолчанию отображалась, когда входящий запрос отличается от установленной по умолчанию установки Drupal, например страницы ошибки.

4. Настройте веб-сервер так, чтобы перенаправлять все запросы, поступающие на ваш сервер, которые не относятся к соответствующему домену для перенаправления на правильное доменное имя.

Настройка безопасности доверенного хоста в Drupal 8

По состоянию на январь 2015 года Drupal 8 поддерживает «шаблоны доверенных хостов», где вы можете (и должны) указывать набор регулярных выражений, которым должны соответствовать домены во входящих запросах. Пример конфигурации в settings.php будет выглядеть так:

$settings['trusted_host_patterns'] = [
  '^www\.example\.com$',
];

См. выше запись изменений для более подробной информации. Обратите внимание, что если вы занимаетесь локальной разработкой, вы можете (временно) заблокировать свой сайт с помощью вышеуказанной конфигурации самостоятельно. В этом случае вы должны добавить шаблон доверенного хоста для '^ localhost $'.

Настройка доверенного хоста для MAMP 3

Что касается локальной разработки, параметр MAMP (3.5.2) «^ localhost $» выдает сообщение об ошибке «Указанное имя хоста недопустимо для этого сервера» и не загружает сайт. Нашел решение, изменив его с именем сайта без номера порта. В моем тестовом сайте "drupal8":

$settings['trusted_host_patterns'] = [
  '^drupal8$',
];

сделал Trusted Host активным.

ПРИМЕЧАНИЕ: на MAMP 4.2 '^ localhost $' работает просто отлично.

Настройка доверенного хоста для Acquia Dev Desktop 2 (протестирована с Drupal 8.6.2 и PHP 7.2.8)

Если вы используете Acquia Dev Desktop 2, попробуйте следующий шаблон доверенного хоста. Измените "sitename" на название вашего сайта:

$settings['trusted_host_patterns'] = array(
    '^sitename\.dd$',
);

Настройка доверенного хоста для XAMPP (протестировано с Drupal 8.4.0 и PHP 7.1.8)

Чтобы включить механизм доверенных хостов, нам нужно включить наши допустимые хосты в $settings ['trusted_host_patterns'].

Откройте файл «settings.php» и обновите приведенный ниже код, чтобы включить настройку доверенного хоста:

$settings['trusted_host_patterns'] = [
'^localhost$',                              
'^192\.168\.00\.52$',
'^127\.0\.0\.1$',
];

Тут,

• '^ localhost $',: это позволит сайту работать только с localhost.
• '^192\.168\.00\.52$',: это позволит сайту запускаться только с системного IP-адреса (разные системы имеют разные IP-адреса).
• '^127\.0\.0\.1$',: это позволит сайту работать только с 127.0.0.1 вместо localhost.

Примечание. При запуске мультисайта укажите все шаблоны хостов, которые разрешены сайтом.

Настройки доверенного хоста для Lando (протестировано с Drupal 8.7.10 и PHP 7.2)

Чтобы включить механизм доверенных хостов, нам нужно включить наши допустимые хосты в $settings['trusted_host_patterns'].

Откройте файл settings.php и обновите приведенный ниже код, чтобы включить настройку доверенного хоста:

$settings['trusted_host_patterns'] = [
  '^'.getenv('LANDO_APP_NAME').'\.lndo\.site$',      # lando proxy access
  '^localhost$',                                     # localhost access
  '^'.getenv('LANDO_APP_NAME').'\.localtunnel\.me$', # lando share access
  '^192\.168\.1\.100$'                               # LAN IP access
];

Примечание. Контейнер Lando содержит больше переменных среды, которые можно использовать для установки правильных учетных данных базы данных. Для этого взгляните на $lando_info=json_decode(getenv ('LANDO_INFO'), TRUE); или проверить phpinfo () ;.