Então, fui encarregado de pesquisar um problema identificado por uma verificação de segurança da web da Acunetix.
Aqui estão os detalhes sobre a verificação: Host_header_attack
Detecção automatizada de ataques de cabeçalho de host
Eu não posso postar mais de dois links ainda, já que não tenho reputação suficiente, mas a referência skeletonscribe no primeiro dos links acima entra em mais detalhes sobre a exploração e parece ser a principal fonte sobre o assunto .
As soluções alternativas sugeridas sugerem o uso de aplicativos e hosts virtuais padrão 'fictícios' usando SERVER_NAME em vez de usar o Cabeçalho do host . Essas sugestões são ótimas quando se fala de um verdadeiro servidor de origem, mas não tanto quando você está usando um proxy reverso.
Nosso site que está sendo verificado pela Acunetix é configurado como um servidor de aplicativos localizado atrás de um proxy reverso. No nosso caso, o proxy reverso é iPlanet, mas eu confirmei o mesmo comportamento no Apache 2.4.7 com mod_proxy . Veja como funciona e por que ele dispara a digitalização Acunetix.
Quando uma solicitação é feita usando um URI absoluto (como faz o scanner), o servidor é, de acordo com a especificação RFC, destinado a ignorar o cabeçalho do Host e, em vez disso, usar o host que está dentro do URI absoluto. Esse é o comportamento que vemos e, como resultado, o host virtual correto é selecionado, mesmo se o cabeçalho do Host tiver um valor incorreto / malicioso. Até aí tudo bem.
O problema surge quando o proxy reverso passa essa solicitação para o servidor de origem de backend. Quando isso acontece, ele passa o cabeçalho original do host junto com a solicitação. Se o cabeçalho do Host tiver um valor incorreto ou mal-intencionado, ele será transmitido de volta ao servidor de origem. Se o servidor de origem não implementar hosts virtuais, não será necessário verificar se o cabeçalho do host está correto.
O resultado disso é que qualquer aplicativo em execução no servidor de origem / aplicativo de origem que tentar usar o valor do cabeçalho do host estará usando o valor do host mal-intencionado. O uso do SERVER_NAME não é de uso nesta instância, pois o nome do servidor (ou host verdadeiro) do site não é encaminhado pelo proxy reverso e o servidor de origem ainda responde com o valor do cabeçalho do Host. Usar UseCanonicalName e a diretiva ServerNam e aqui também é inútil, já que você precisa do nome do servidor da solicitação original, que pode ter mais de um valor.
Esse 'ataque' foi identificado em 2013, mas não consigo encontrar muitas informações sobre ele que não apenas reiterem os detalhes das referências acima. Não é um problema comum, porque os clientes HTTP não enviam URIs absolutos, a menos que estejam conversando com servidores proxy de encaminhamento. Isso significa que todas as solicitações regulares serão relativas a URIs e esse problema desaparece (os cabeçalhos de host mal-intencionado ficam presos no host virtual 'simulado' ou padrão no proxy reverso).
Eu criei uma solução alternativa, em que o proxy reverso ativamente define o cabeçalho do Host para o SERVER_NAME antes que a solicitação seja enviada para o back-end. Isso funciona, mas me preocupo se pode ser uma solução que vai contra as práticas / padrões da aposta. Definir o cabeçalho do Host como este quebra algo? Nós pensamos nisso, mas não consigo pensar em um cenário em que isso aconteceria. Eu estarei ligando para a Oracle amanhã para obter feedback deles.
Parece-me que este pode ser um caso tão periférico, que é apenas um descuido nos dois produtos de servidor web que experimentei, mas não consigo imaginar que algo iria passar tanto tempo sem ser abordado. Eu devo estar perdendo alguma coisa.
Desculpe, é muito tempo, mas alguma ideia? :) A parte 'questão' deste ensaio seria esta:
- A minha solução alternativa acima seria uma boa solução ou quebraria as coisas?
- Existe uma solução conhecida para este problema?