PHP, Python e outros aplicativos de sites expõem vulnerabilidade de proxy remoto: httpoxy

[Shenzhen] Yuanchuanghui: 17h26, o salão de festas está esperando por você.”

Esta é uma vulnerabilidade direcionada a aplicativos CGI em PHP, Go, Python e outras linguagens.

httpoxy é o nome de uma família de vulnerabilidades que afetam aplicativos executados em CGI ou semelhante a CGI. Simplificando, é um problema de conflito de namespace.

RFC 3875 (CGI) define como Proxypreencher diretamente variáveis de ambiente a partir do cabeçalho da solicitação HTTPHTTP_PROXY
HTTP_PROXYÉ uma variável de ambiente comumente usada para configurar agentes de saída

Esta falha permite ataques remotos. Se você estiver executando um programa PHP ou CGI, deverá bloquear o cabeçalho do Proxy imediatamente! imediatamente! Veja abaixo instruções específicas. httpoxy é uma vulnerabilidade de aplicativo da web do lado do servidor. Se você não implantar esse código no lado do servidor, não precisa se preocupar.

O que acontece se meu aplicativo web tiver essa vulnerabilidade?

Quando um cliente HTTP que explora esta vulnerabilidade faz uma solicitação, ele pode:

Solicitações de proxy para outros URLs por meio de seu aplicativo da web
Peça diretamente ao seu servidor para abrir o endereço remoto e a porta especificados
Desperdice recursos do servidor e acesse recursos especificados para invasores

A vulnerabilidade httpoxy é muito fácil de explorar. Esperamos que o pessoal de segurança verifique esta vulnerabilidade o mais rápido possível e a corrija rapidamente.

Quais são afetados?

Vulnerabilidades de segurança podem existir nas seguintes situações:

O código é executado em um contexto CGI, que HTTP_PROXYse torna uma variável de ambiente real ou simulada
Um cliente HTTP confiável HTTP_PROXYque suporta funcionalidade de proxy
O cliente iniciará uma solicitação HTTP (ou HTTPS) dentro da solicitação

As seguintes situações são ambientes onde esta falha foi encontrada:

linguagem	ambiente	Cliente HTTP
PHP	php-fpm mod_php	Beba 4+ Artax
Pitão	wsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScript	solicitações de
Ir	net/http/cgi	rede/http

Certamente existem muitas linguagens e ambientes que não identificamos quanto a defeitos.

PHP

A existência da falha depende do código do seu aplicativo e da biblioteca PHP, mas o impacto parece ser muito difundido
Desde que uma biblioteca com esta falha seja utilizada no processo de processamento de solicitações de usuários, ela poderá ser explorada
Se você usa uma biblioteca com esta falha, a falha afeta qualquer versão do PHP
- Pode até afetar ambientes de execução PHP alternativos, como HHVM implantado no modo FastCGI
Está confirmado que bibliotecas como Guzzle e Artax foram afetadas, e pode haver muitas mais bibliotecas que também foram afetadas.
- Guzzle 4.0.0rc2 e versões posteriores são afetadas, Guzzle 3 e versões inferiores não são afetadas
- Outros exemplos incluem a classe de utilitário StreamContextBuilder do Composer

Por exemplo, se você usar o módulo Guzzle 6 no Drupal para iniciar solicitações de saída (como solicitar uma API meteorológica), as solicitações iniciadas pelo módulo terão essa falha httpoxy.

Pitão

O código Python só apresenta defeito quando implantado no modo CGI. De modo geral, o código defeituoso usa wsgiref.handlers.CGIHandlerum controlador CGI como.
- Os aplicativos da web Python implantados da maneira normal não são afetados (a maioria das pessoas usa WSGI ou FastCGI, esses dois não são afetados), portanto, há muito menos aplicativos Python afetados do que PHP
- wsgi não é afetado porque os.environ não está contaminado por dados CGI
A biblioteca de solicitações defeituosas deve ser confiável e usada os.environ['HTTP_PROXY']e não faz verificação de conteúdo

Ir

O código Go deve ser implantado em CGI para ser afetado. O código geralmente afetado usará net/http/cgio pacote
- Assim como o Python, esta não é a maneira usual de implantar o Go como um aplicativo da web. Portanto, há muito poucos casos de serem afetados
- Em comparação, o pacote Go net/http/fcginão define variáveis de ambiente reais, portanto não é afetado
A versão defeituosa net/httpprecisa ser confiável e usada em solicitações de saída HTTP_PROXY, sem verificação de conteúdo

Corrija agora

ProxyA melhor solução é bloquear os cabeçalhos de solicitação antes que eles ataquem seu aplicativo . É fácil e seguro.

Diz-se que é seguro porque Proxyo cabeçalho da solicitação não é definido pela IETF e não está listado no registro de cabeçalho de mensagem da IANA . Isso indica que o uso deste cabeçalho não é padrão e nem mesmo é usado ad hoc
Clientes e servidores HTTP em conformidade com os padrões nunca devem ler ou enviar este cabeçalho
Você pode remover esse cabeçalho da solicitação ou bloquear solicitações usando-o inteiramente.
Você pode consertar isso sozinho se o upstream não lançar um patch
- Verificar as solicitações HTTP à medida que elas chegam pode corrigir muitos aplicativos defeituosos de uma só vez
- A seleção de aplicativos por trás de proxies reversos e firewalls de aplicativos ProxyOs cabeçalhos de solicitação são seguros

Como bloquear Proxycabeçalhos de solicitação depende da sua configuração. A maneira mais fácil é bloquear esse cabeçalho no firewall do seu aplicativo web ou diretamente no Apache e Nginx. Aqui estão algumas dicas sobre como fazer isso:

Nginx/FastCGI

Use a seguinte instrução para bloquear os cabeçalhos de solicitação passados para PHP-FPM e PHP-PM. Esta instrução pode ser colocada em fastcgi.conf ou fastcgi_param (dependendo de qual arquivo de configuração você usa):

fastcgi_param HTTP_PROXY "";

O PHP apresenta defeito no modo FastCGI (mas a maioria das outras linguagens que usam Nginx FastCGI não são afetadas).

Apache

Para saber a extensão específica do impacto no Apache, bem como em outros projetos de software Apache, como o Tomcat, é recomendável consultar o anúncio oficial da Apache Software Foundation . Aqui estão algumas mensagens principais:

Se você usar o servidor Apache HTTP mod_cgipara executar scripts escritos em Go ou Python, eles serão afetados (onde HTTP_PROXYas variáveis de ambiente são "reais"). Por mod_phpser usado em scripts PHP, essa falha também existe.

Se você usar o módulo mod_headers , poderá cancelar a definição Proxydos cabeçalhos da solicitação antes de processar a solicitação com a seguinte configuração:

RequestHeader unset Proxy early

Se você usar o módulo mod_security , poderá usar uma SecRuleregra para negar Proxysolicitações com cabeçalhos de solicitação. Aqui está um exemplo, certifique-se de SecRuleEngineque esteja ativado. Você pode ajustá-lo de acordo com sua situação.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Finalmente, se você usar o Apache Traffic Server, ele não será afetado. No entanto, você pode usá-lo para remover o cabeçalho da solicitação de proxy para proteger outros serviços por trás dele. Consulte as orientações da ASF para obter detalhes .

HAProxy

Remova o cabeçalho da solicitação por meio da seguinte configuração:

http-request del-header Proxy

Verniz

Para cancelar este cabeçalho, coloque-o na seção vcl_recv existente:

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD retransmitido

Use a instrução a seguir para remover esse cabeçalho. Coloque-o dentro de um filtro existente:

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd (<= 1.4.40)

Retorna Proxysolicitações contendo cabeçalhos.

Crie um /path/to/deny-proxy.luaarquivo e torne-o somente leitura para lighttpd com o seguinte conteúdo:

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

Modifique lighttpd.confpara carregar mod_magneto módulo e execute o código lua acima:

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (em desenvolvimento)

ProxyRetire os cabeçalhos das solicitações . Adicione a seguinte declaração a lighttpd.confele:

req_header.remove "Proxy";

A correção do PHP do lado do cliente não tem efeito

Não há soluções do lado do usuário para resolver a falha, então não se preocupe:

Usar unset($_SERVER['HTTP_PROXY'])não afetará getenv()o valor retornado, portanto é inútil
O uso putenv('HTTP_PROXY=')não tem efeito (putenv só pode afetar valores de variáveis de ambiente reais, não de cabeçalhos de solicitação)

História do httpoxy

A vulnerabilidade foi descoberta pela primeira vez há 15 anos.

Em março de 2001, Randal L. Schwartz descobriu esse defeito no libwww-perl e o corrigiu.

Em abril de 2001, Cris Bailiff descobriu essa falha no curl e a corrigiu.

A falha foi descoberta por Akira Tanaka da equipe Ruby em julho de 2012 na implementação Net::HTTPdoHTTP_PROXY

A falha foi mencionada na lista de discussão nginx em novembro de 2013. O descobridor Jonathan Matthews não tinha tanta certeza, mas descobriu que estava certo.

Stefan Fritsch mencionou isso em fevereiro de 2015 na lista de discussão Apache httpd-dev.

A falha foi descoberta por Scott Geary, da equipe de segurança da Vend, em julho de 2016 e afeta muitas linguagens de programação e bibliotecas modernas, como PHP.

Portanto, essa falha está adormecida há muitos anos, e muitas pessoas descobriram sua existência em diversos aspectos, mas não consideraram seu impacto em outras linguagens e bibliotecas. Os pesquisadores de segurança criaram um site especificamente para esse fim: https://httpoxy.org/ onde você pode saber mais.