A única maneira segura de fazer isso
Todas as outras respostas nesta página têm implicações de segurança que você precisa estar ciente.
O único método seguro garantido de recuperar o domínio atual
é para 𝔂𝓸𝓾𝓻𝓼𝓮𝓵𝓯 𝓲𝓽 𝓲𝓷 𝓪 𝓼𝓮𝓬𝓾𝓻𝓮 𝓵𝓸𝓬𝓪𝓽𝓲𝓸𝓷.
A maioria das estruturas cuida de armazenar o domínio para você, portanto, você deve consultar a documentação para sua estrutura específica. Se você não estiver usando uma estrutura, considere armazenar o domínio em um dos seguintes locais:
+ ------------------------------------------------- --- + ----------------------------------- +
| Métodos seguros de armazenamento do domínio | Usado por |
+ ------------------------------------------------- --- + ----------------------------------- +
| Um arquivo de configuração | Joomla, Drupal / Symfony |
| O banco de dados | WordPress |
| Uma variável ambiental | Laravel
| Um registro de serviço | DNS do Kubernetes |
+ ------------------------------------------------- --- + ----------------------------------- +
Você pode usar o seguinte ... mas eles não são seguros
Os hackers podem fazer com que essas variáveis produzam o domínio que quiserem. Isso pode levar a envenenamento de cache e ataques de phishing quase imperceptíveis.
$_SERVER['HTTP_HOST']
Isso obtém o domínio dos cabeçalhos de solicitação abertos à manipulação por hackers . Mesmo com:
$_SERVER['SERVER_NAME']
Este pode ser melhorado se a configuração do Apache usecanonicalname estiver desativada; nesse caso $_SERVER['SERVER_NAME']
, não será mais permitido preencher valores arbitrários e estará seguro. No entanto, isso não é o padrão e não é tão comum em uma instalação.
Em sistemas populares
Abaixo está como você pode obter o domínio atual nas seguintes estruturas / sistemas:
WordPress
$urlparts = parse_url(home_url());
$domain = $urlparts['host'];
Se você estiver construindo um URL no WordPress, use home_url ou site_url , ou qualquer outra função de URL .
Laravel
request()->getHost()
A request()->getHost
função é herdada do Symfony e está segura desde que o CVE-2013-4752 de 2013 foi corrigido.
Drupal
O instalador ainda não se encarrega de torná-lo seguro ( problema nº 2404259 ). Mas no Drupal 8 há documentação que você pode seguir em Configurações do host confiável para proteger sua instalação do Drupal, após a qual o seguinte pode ser usado:
\Drupal::request()->getHost();
Outras estruturas
Sinta-se à vontade para editar esta resposta para incluir como obter o domínio atual em sua estrutura favorita. Ao fazer isso, inclua um link para o código-fonte relevante ou para qualquer outra coisa que me ajude a verificar se a estrutura está fazendo as coisas com segurança.
Termo aditivo
Exemplos de exploração:
O envenenamento por cache pode ocorrer se uma botnet solicitar continuamente uma página usando o cabeçalho de hosts incorretos. O HTML resultante incluirá links para o site do invasor, onde eles poderão fraudar seus usuários. Inicialmente, os links maliciosos serão enviados apenas de volta ao hacker, mas se o hacker fizer solicitações suficientes, a versão maliciosa da página acabará no seu cache, onde será distribuída a outros usuários.
Um ataque de phishing pode ocorrer se você armazenar links no banco de dados com base no cabeçalho do host. Por exemplo, digamos que você armazene o URL absoluto nos perfis de um usuário em um fórum. Ao usar o cabeçalho errado, um hacker pode fazer com que qualquer pessoa que clica no link do perfil seja enviada para um site de phishing.
O envenenamento por redefinição de senha pode ocorrer se um hacker usar um cabeçalho de host malicioso ao preencher o formulário de redefinição de senha para um usuário diferente. Esse usuário receberá um e-mail contendo um link de redefinição de senha que leva a um site de phishing.
Aqui estão alguns exemplos mais maliciosos
Advertências e notas adicionais:
- Quando usecanonicalname está desativado,
$_SERVER['SERVER_NAME']
é preenchido com o mesmo cabeçalho$_SERVER['HTTP_HOST']
teria usado de qualquer maneira (mais a porta). Esta é a configuração padrão do Apache. Se você ou o devops ativam isso, então você está bem - ish - mas você realmente quer confiar em uma equipe separada, ou em você mesmo daqui a três anos, para manter o que parece ser uma configuração menor em um ambiente não -valor padrão? Mesmo que isso torne as coisas seguras, eu recomendaria não confiar nessa configuração.
- O Redhat, no entanto, é ativado por via canônica por padrão [ fonte ].
- Se serverAlias for usado na entrada de hosts virtuais e o domínio aliasado for solicitado,
$_SERVER['SERVER_NAME']
não retornará o domínio atual, mas retornará o valor da diretiva serverName.
- Se o serverName não puder ser resolvido, o comando hostname do sistema operacional será usado em seu lugar [origem] .
- Se o cabeçalho do host for deixado de fora, o servidor se comportará como se o usecanonical estivesse em [origem] .
- Por fim, tentei explorar isso no meu servidor local e não consegui falsificar o cabeçalho do host. Não tenho certeza se houve uma atualização no Apache que abordou isso, ou se eu estava apenas fazendo algo errado. Independentemente disso, esse cabeçalho ainda seria explorável em ambientes onde os hosts virtuais não estão sendo usados.
Little Rant:
Esta pergunta recebeu centenas de milhares de visualizações sem uma única menção aos problemas de segurança em questão! Não deve ser assim, mas apenas porque uma resposta de estouro de pilha é popular, isso não significa que é segura.