Configuração de Host Confiável

Esta documentação é incompleta. Obtenha mais informações.

Proteção contra Ataques de Cabeçalho HTTP HOST (não deixe seu site pensar que é outro)

O Drupal 7 adicionou uma nova funcionalidade ao núcleo que não se destina à interação direta do usuário, mas às vezes é chamada de poormanscron. Essa funcionalidade executa tarefas periódicas do site Drupal, como limpeza de arquivos de log, envio de emails e limpeza de caches. Essa funcionalidade combinada com a detecção dinâmica de "URL base" (adicionada em Drupal 4.7) pode levar a algumas situações estranhas. Este artigo é uma descrição de algumas dessas situações estranhas que surgem com ambos os módulos ou ambos, e o que você pode fazer para evitá-las. Os comentários abaixo pressupõem algumas configurações padrão - no final, descrevo como se afastar dessas configurações padrão para evitar esses problemas.

Cenário 1. Recebimento / Envio de Emails de Usuários que são Destinados a Outro Domínio

Esse comportamento é bastante fácil de reproduzir:

1. Aponte um novo domínio para o endereço IP do site existente - vamos chamar o site existente de http://www.example.com, e o novo nome apontando para esse endereço IP será http://other-site.example.org.

2. Visite a URL: http://other-site.example.org/user/password

3. Digite um nome de usuário que provavelmente será usado no site.

Como resultado da etapa 2, a detecção de $base_url assume que seu site é http://other-site.example.org e todos os tokens para email, como [user:one-time-login-url], que contêm links para seu site serão alterados para usar http://other-site.example.org como URL base. O usuário que recebe esse email verá que seu nome de usuário e email para example.com agora estão sendo usados de alguma forma em http://other-site.example.org, o que geralmente é apenas confuso. No entanto, dois cenários ruins podem surgir disso:

• No pior caso, isso pode fazer com que eles cliquem em um link de redefinição de senha que um site mal-intencionado pode usar para fazer login no site em nome desse usuário.
• Eles podem inserir seu nome de usuário/senha em http://other-site.example.org - o chamado ataque de engenharia social - que pode ser usado no site principal.

Cenário 2. Registro em Cache contendo Domínio Incorreto

Um problema semelhante pode ocorrer quando um usuário usa o domínio incorreto para fazer uma solicitação e isso acontece com uma solicitação que preenche um registro em cache com domínios completamente qualificados e dinâmicos nele. Visitas subsequentes que recuperam informações desse cache receberão o nome de domínio incorreto. O cache de página do núcleo do Drupal usa o domínio como parte do ID do cache, impedindo esse problema, mas outros mecanismos de cache podem não ser tão resistentes a esse problema.

Cenário 3: Notificações de Email Contendo Domínio Incorreto

Outro problema pode ocorrer em sites que usam módulos que enviam email durante a execução do cron. Este cenário requer poormanscron com detecção dinâmica de base_url. Se um usuário acidentalmente acionar o poormanscron quando há notificações na fila visitando um nome de domínio incorreto, as notificações serão enviadas com esse domínio incorreto. Os usuários ficarão muito confusos sobre por que o email que esperam receber de um endereço de email em example.com contém links para o domínio http://other-site.example.org.

Soluções para Experiência Confusa com Detecção Dinâmica de Drupal base_url

Existem pelo menos quatro soluções possíveis para esse problema, embora nem todas sejam necessárias para evitar que o problema ocorra. Você deve escolher e selecionar de acordo com seu ambiente.

1. Você pode definir um domínio específico como seu $base_url em sites/default/settings.php. Embora a detecção dinâmica possa ser uma funcionalidade conveniente, também pode causar problemas. Uma maneira de evitar isso é definir um valor permanente.

2. Use um arquivo sites/example.com/settings.php específico e deixe $base_url ser detectado dinamicamente - isso significa que o Drupal responde a todos os subdomínios de example.com, o que pode ou não ser uma vantagem.

3. Configure seu servidor da web para que uma página padrão seja exibida quando uma solicitação recebida diferir da configuração padrão do Drupal configurada, como uma página de erro.

4. Configure o servidor web para redirecionar todas as solicitações recebidas no seu servidor que não pertençam ao domínio correspondente para redirecionar para o nome de domínio correto.

Configuração de Segurança de Host Confiável no Drupal 8

A partir de janeiro de 2015, Drupal 8 suporta "padrões de host confiável", onde você pode (e deve) especificar um conjunto de expressões regulares que os domínios nas solicitações recebidas devem corresponder. Um exemplo de configuração em settings.php seria:

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

Consulte a entrada de changelog acima para mais detalhes. Observe que se você estiver fazendo desenvolvimento local, você pode (temporariamente) bloquear seu site com a configuração acima por conta própria. Nesse caso, você deve adicionar um padrão de host confiável para '^localhost$'.

Configuração de Host Confiável para MAMP 3

Quanto ao desenvolvimento local, a configuração MAMP (3.5.2) '^localhost$' lança uma mensagem de erro "O nome de host especificado é inválido para este servidor" e não carrega o site. Encontrei uma solução alterando-a com o nome do site sem o número da porta. No meu site de teste "drupal8":

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

fez o Host Confiável ativo.

NOTA: no MAMP 4.2, '^localhost$' funciona perfeitamente.

Configuração de Host Confiável para Acquia Dev Desktop 2 (testado com Drupal 8.6.2 e PHP 7.2.8)

Se você estiver usando o Acquia Dev Desktop 2, tente o seguinte padrão de host confiável. Altere "sitename" para o nome do seu site:

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

Configuração de Host Confiável para XAMPP (testado com Drupal 8.4.0 e PHP 7.1.8)

Para ativar o mecanismo de host confiável, precisamos incluir nossos hosts permitidos em $settings['trusted_host_patterns'].

Abra o arquivo "settings.php" e atualize o código abaixo para incluir a configuração de host confiável:

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

Aqui,

• '^localhost$',: isto permitirá que o site seja executado apenas com localhost.
• '^192\.168\.00\.52$',: isto permitirá que o site seja executado apenas com o endereço IP do sistema (diferentes sistemas têm diferentes endereços IP).
• '^127\.0\.0\.1$',: isto permitirá que o site seja executado apenas com 127.0.0.1 em vez de localhost.

Nota: Ao executar um multisite, especifique todos os padrões de host que o site permite.

Configuração de Host Confiável para Lando (testado com Drupal 8.7.10 e PHP 7.2)

Para ativar o mecanismo de host confiável, precisamos incluir nossos hosts permitidos em $settings['trusted_host_patterns'].

Abra o arquivo settings.php e atualize o código abaixo para incluir a configuração de host confiável:

$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
];

Nota: O contêiner Lando contém mais variáveis de ambiente que podem ser usadas para definir as credenciais corretas do banco de dados. Para fazer isso, consulte $lando_info=json_decode(getenv('LANDO_INFO'), TRUE); ou verifique phpinfo();.