Benoit Chesneau

Um problema de HTTP Request Splitting existe em `hackney http connect` devido à neutralização inadequada de sequências CRLF em cabeçalhos HTTP. Quando um proxy HTTP CONNECT retorna uma resposta 407, a função `hackney http connect:handle proxy auth/11` executa um callback `proxy auth fun` e grava o binário retornado diretamente na linha `Proxy-Authorization` da solicitação de repetição sem validação. Se o valor retornado contiver um Carriage Return (CR), Line Feed (LF) ou byte NUL, um invasor pode injetar linhas de cabeçalho adicionais na solicitação enviada ao proxy. Isso ocorre quando o callback deriva seu valor de dados não confiáveis, como os cabeçalhos de desafio do proxy.

Existe um problema onde um servidor de redirecionamento pode obter credenciais de `basic auth` e `cookie` por meio de um redirecionamento no mesmo host para um esquema ou porta diferente. Quando `follow redirect` está habilitado, a função `hackney:follow redirect/10` em `src/hackney.erl` reemite solicitações para o destino `Location`. A verificação realizada por `hackney:maybe strip auth on redirect/3` compara apenas o nome do host das URLs atual e de redirecionamento. Consequentemente, um redirecionamento de `https` para `http` no mesmo host envia os cabeçalhos `Authorization` e `Cookie` em texto simples, permitindo que um invasor no caminho os intercepte. Da mesma forma, um redirecionamento para uma porta diferente no mesmo host envia essas credenciais para um serviço diferente. Isso ocorre via HTTP/1.1 e HTTP/2 quando `location trusted` não está configurado.

Um conflito de interpretação em `hackney url` permite Server Side Request Forgery (SSRF). Isso ocorre quando um host é fornecido como um literal IPv6 entre colchetes codificado em percentual ou um literal de IP com um ponto final. Enquanto uma lista de permissões (allowlist) do chamador usando `uri string:parse/1` e `inet:parse address/1` pode não reconhecer esses valores como endereços IP, o hackney ainda se conecta ao endereço indicado. O mesmo se aplica a alvos `Location` quando redirecionamentos são seguidos. O problema decorre do fato de `hackney url:normalize/2` passar valores decodificados para `inet parse:address/1` como estão, enquanto o caminho de conexão em `hackney happy:parse address/1` remove colchetes circundantes e o resolvedor ignora pontos finais, permitindo que essas formas ignorem o controle de literal de IP. Aplicações que utilizam uma lista de permissões de IP para evitar requisições a endereços internos, como loopback ou metadados de link-local, estão suscetíveis.

Um problema de alocação de recursos em `hackney conn` permite que um servidor HTTP malicioso esgote a memória do cliente ao enviar um corpo de resposta excessivamente grande ou altamente compactado. As funções `hackney:request/5` e `hackney:body/1` retornam o corpo completo da resposta sem limites sobre o quanto o processo de conexão armazena em buffer. Especificamente, `hackney conn:read full body/2` e os acumuladores HTTP/2 e HTTP/3 anexam cada fragmento até que o corpo termine. Quando a opção `{auto decompress, true}` é utilizada, o corpo armazenado em buffer é inflado em uma única etapa usando `zlib:gunzip/1` ou `zlib:inflate/2`, que retornam toda a saída de uma vez. Isso pode levar a uma amplificação significativa de memória; por exemplo, um corpo gzip de 1 MB pode inflar para 1 GB.

Um loop infinito existe no analisador do cabeçalho de resposta Alt-Svc em `src/hackney altsvc.erl`. Quando a função `parse token/2` recebe um byte que não seja um token, espaço em branco ou vírgula (como !, @, = ou ;), ela retorna a entrada inalterada. Da mesma forma, a função `skip comma/1` retorna o buffer inalterado se o primeiro byte não for uma vírgula. Isso faz com que a função `parse entries/2` realize a recursão com dados idênticos, criando um loop recursivo de cauda infinito que consome 100% do escalonador de CPU e impede que o processo solicitante retorne. O ponto de entrada `parse and cache/3` é chamado sincronicamente em cada resposta HTTP, o que significa que um cabeçalho de resposta `Alt-Svc: !` de um único byte de qualquer origem HTTP pode causar o travamento.

Um problema no analisador de URL em `src/hackney url.erl` permite a exaustão de recursos. O analisador utiliza a função `binary to atom/2` para converter esquemas de URL não reconhecidos em átomos BEAM permanentes. Como os átomos BEAM não são coletados pelo garbage collector e a tabela de átomos possui um limite rígido de 1.048.576 entradas, um invasor pode esgotar essa tabela fornecendo URLs com prefixos de esquema personalizados. Isso pode ser feito por meio de alvos de requisição, URLs de webhook configuradas ou cabeçalhos Location durante redirecionamentos, resultando no travamento de toda a VM BEAM com um erro de `system limit`.

A Neutralização Imprópria de Sequências CRLF, também conhecida como CRLF Injection, permite a Divisão de Resposta HTTP (HTTP Response Splitting). A função `setcookie/3` em `src/hackney cookie.erl` valida os argumentos Name e Value contra caracteres de controle e CRLF, mas concatena as opções de domínio e caminho no iolist de saída sem verificações equivalentes. Um invasor que controle essas opções, como ao fornecer um valor de cabeçalho Host como o domínio do cookie ou um caminho de solicitação como o caminho do cookie, pode injetar sequências CRLF literais e cabeçalhos Set-Cookie adicionais arbitrários na resposta HTTP.

Um problema de exposição de dados sensíveis existe onde o manipulador de redirecionamento HTTP/3 em `src/hackney h3.erl` passa os cabeçalhos da requisição original para o destino do redirecionamento sem realizar verificações de cross-origin. Se um cliente fizer uma requisição HTTP/3 com `follow redirect` habilitado e incluir cabeçalhos `Authorization` ou `Cookie`, um servidor que responder com um redirecionamento 3xx para um host diferente fará com que o cliente encaminhe essas credenciais integralmente para a nova origem. Isso ocorre porque o `hackney h3.erl` carece da proteção fornecida pela função `maybe strip auth on redirect()` encontrada no módulo principal `hackney.erl`.

O Consumo Não Controlado de Recursos no transporte SOCKS5 em `src/hackney socks5.erl` permite flooding. Embora o tempo limite fornecido pelo chamador seja aplicado durante a fase de negociação SOCKS5, a atualização da conexão para TLS através da função `ssl:connect/2` assume um tempo limite infinito por padrão, pois a variável `Timeout` não é encaminhada. Consequentemente, um proxy SOCKS5 malicioso que complete o handshake e então fique inativo ou envie um TLS ServerHello parcial pode fazer com que o processo de conexão bloqueie indefinidamente, ignorando as opções `connect timeout` ou `recv timeout`.

A Neutralização Imprópria de Sequências CRLF, também conhecida como CRLF Injection, permite a Divisão de Requisição/Resposta HTTP (HTTP Request/Response Splitting). O código de upgrade de WebSocket em `src/hackney ws.erl` copia o host, caminho, cabeçalhos (`ExtraHeaders`) e opções de protocolos do mapa de opções fornecido pelo chamador para o registro interno `#ws data{}` em `init/1` e, em seguida, os insere literalmente na requisição de upgrade HTTP/1.1 bruta por concatenação binária em `do handshake/1`. Como nenhuma remoção de CRLF ou NUL é realizada nesses quatro pontos de injeção, um invasor que controle essas opções — por exemplo, encaminhando componentes de URL ou valores de cabeçalho de entradas não confiáveis para `hackney ws:start link/1` — pode injetar cabeçalhos HTTP arbitrários na requisição de upgrade de WebSocket de saída. Isso pode levar à injeção de cabeçalhos, falsificação de credenciais (credential spoofing) para o servidor upstream, envenenamento de logs e cache, ou contrabando de requisições (request smuggling) via proxies intermediários.

O cliente WebSocket em `src/hackney ws.erl` não impõe limites superiores ao consumo de memória em três caminhos de código, permitindo inundação (flooding). Primeiro, a função `read handshake response/3` acumula bytes recebidos em um buffer sem limite de tamanho; um servidor que transmite bytes sem a sequência de terminação necessária faz com que o buffer cresça até que a memória seja esgotada. Segundo, as funções `parse payload/9` e `parse active payload/8` não validam o comprimento declarado da carga útil do frame, que pode chegar a 2^63-1 bytes conforme a RFC 6455, levando a condições de Out-of-Memory (OOM) quando um servidor anuncia um frame muito grande. Terceiro, o campo `frag buffer` em `#ws data{}` acumula frames de continuação indefinidamente se um servidor enviar um fluxo de frames fragmentados não finais sem um frame final. Um invasor precisa apenas controlar o servidor WebSocket ao qual o cliente se conecta, sem a necessidade de autenticação ou configuração especial.

A Neutralização Imprópria de Sequências CRLF permite a Divisão de Requisição HTTP (HTTP Request Splitting). O software não realiza a codificação percentual (percent-encode) de caracteres de retorno de carro (`r`) ou alimentação de linha (` `) no componente de consulta da URL antes de construir o alvo da requisição HTTP/1.1. Especificamente, a função `hackney url:make url/3` passa o binário da consulta diretamente sem validação ou escape, violando a seção 3.4 da RFC 3986. Um atacante que controle parte de uma URL pode injetar sequências CRLF brutas na string de consulta, permitindo a injeção de cabeçalhos HTTP arbitrários ou a divisão da requisição HTTP.

Um conflito de interpretação permite a ocorrência de Server Side Request Forgery (SSRF), uma falha onde um invasor pode induzir o servidor a fazer requisições para um local não pretendido. A função `hackney url:normalize/2` decodifica a URL do componente de host após a URL ter sido analisada em um registro `#hackney url{}`. Como as funções `uri string:parse/1` e `inet:parse address/1` do OTP não decodificam escapes de porcentagem no host, uma URL contendo caracteres codificados em porcentagem pode burlar validadores de lista de permissões (allowlist) que não reconhecem a string codificada como um endereço IP. Posteriormente, o normalizador decodifica o host (por exemplo, convertendo `%31%32%37%2E%30%2E%30%2E%31` para `127.0.0.1`), permitindo conexões TCP para a interface de loopback, serviços de metadados de instâncias de nuvem (169.254.169.254), redes RFC1918 e interfaces de administração locais. Isso ocorre porque a função `hackney:request/5` sempre invoca `hackney url:normalize/2` sem um mecanismo de exclusão para requisições que utilizam URLs binárias ou em lista.

Uma alocação de recursos sem limites ou controle de fluxo permite a inundação (flooding). A função `await response loop/6` em `hackney h3` acumula o corpo da resposta HTTP/3 na memória sem um limite de tamanho. Como a cláusula de tempo limite funciona como um temporizador de inatividade por mensagem que é redefinido ao receber chunks, mensagens de manutenção ou quadros de configuração, em vez de um prazo fixo, um servidor HTTP/3 malicioso pode manter o loop ativo indefinidamente. Ao emitir pequenos chunks pouco antes da expiração do tempo limite com `Fin` definido como falso e omitindo um quadro final, o servidor faz com que o buffer de acumulação cresça linearmente, esgotando o heap do processo BEAM e levando a uma condição de falta de memória (out-of-memory). Este problema ocorre quando a aplicação utiliza o transporte HTTP/3 através do `hackney h3` ou ao passar `{transport, h3}` para `hackney:request/5`.