Ulisesgascon

Quando um Agente compõe interceptores de redirecionamento e cache compartilhado, uma resposta em cache revalidada com uma requisição condicional pode ser incorretamente validada por uma resposta 304 Not Modified de uma origem diferente. Isso ocorre porque o manipulador de redirecionamento remove os cabeçalhos de credenciais vinculados à origem, mas não remove os validadores `If-None-Match` ou `If-Modified-Since` gerados pelo cache. Consequentemente, o destino do redirecionamento recebe o validador da origem original, e o sistema trata a resposta 304 como uma revalidação bem-sucedida. Isso pode fazer com que um cache compartilhado forneça uma resposta autenticada, como uma protegida por um cabeçalho `Authorization`, a um chamador não autenticado.

Quando o interceptor de redirecionamento e um cache de resposta compartilhado são usados juntos, uma requisição autenticada redirecionada para um alvo de mesma origem armazena a resposta final sob a chave de cache da requisição original. Como essa chave omite credenciais e não possui um cabeçalho Vary, requisições subsequentes de usuários anônimos ou diferentes podem receber o corpo da resposta privada do primeiro usuário, resultando na divulgação de respostas privadas em cache entre usuários.

Existe um problema no cliente HTTP onde o interceptor de cache, quando utilizado com um manipulador downstream que gera exceções durante o processamento da resposta, permite que um lançamento assíncrono escape como uma exceção não capturada ou rejeição de promessa não tratada. Isso ocorre durante a reprodução de uma resposta em cache, o que encerra o processo do Node.js. Um servidor HTTP malicioso ou comprometido pode desencadear isso fornecendo uma resposta cacheável que cause um erro na reprodução, como durante uma revalidação 304 de uma entrada obsoleta, impactando a disponibilidade do sistema. Exemplos de manipuladores que podem causar isso incluem o interceptor de dump excedendo seu `maxSize` ou o interceptor de descompressão rejeitando mais de cinco valores de Content-Encoding.

A função `fetch` verifica incorretamente os metadados de Subresource Integrity (SRI) ao dividir a string de integridade apenas por espaços simples. Como a gramática SRI permite qualquer espaço em branco ASCII, incluindo tabulações horizontais, qualquer digesto precedido por esse espaço é tratado como um token não reconhecido e ignorado. Se não restarem algoritmos reconhecidos, a lista de integridade é tratada como vazia, permitindo que um servidor retorne um corpo de resposta diferente do digesto fixado sem gerar um erro de integridade. Isso permite que um invasor que controle o corpo da resposta entregue bytes maliciosos a uma aplicação que utilize valores SRI cercados por espaços em branco.

Quando um Agente sem origem compõe os interceptores de redirecionamento e cache compartilhado, o sistema decide se armazena a resposta final sob a chave de solicitação original inspecionando apenas o salto de redirecionamento final. Isso permite que um redirecionamento que passe por uma origem não confiável e retorne a uma origem confiável seja armazenado no cache sob a chave confiável. Consequentemente, o cabeçalho `Vary` de um salto intermediário pode ser descartado, podendo servir respostas que variam conforme `Authorization` ou `Cookie` para usuários diferentes. Além disso, o status `no-cache` ou `default-uncacheable` de um salto intermediário pode ser ignorado, permitindo que um redirecionamento não armazenável seja tratado como uma entrada de cache. Um invasor que controle um alvo de redirecionamento de uma URL confiável pode envenenar a entrada do cache ou fazer com que uma resposta privada, por usuário, seja servida a chamadores posteriores.

O interceptor de redirecionamento falha ao remover cabeçalhos sensíveis—incluindo `Authorization`, `Cookie`, `Proxy-Authorization` e `Host`—quando uma requisição é redirecionada para uma origem diferente, caso os cabeçalhos da requisição sejam fornecidos como um array de tuplas de nome e valor. Nesse cenário, o manipulador de redirecionamento interpreta erroneamente as tuplas como uma lista plana, impedindo que os nomes dos cabeçalhos coincidam e permitindo que os cabeçalhos sensíveis permaneçam. Se um interceptor de normalização de cabeçalhos, como cache ou deduplicate, for composto fora do interceptor de redirecionamento, esses cabeçalhos retidos são serializados na requisição de origem cruzada, podendo expor credenciais vinculadas à origem para um destino não relacionado.

Este plugin encaminha solicitações para um servidor HTTP upstream. Ele falha ao validar adequadamente os caminhos de proxy porque verifica apenas segmentos de ponto com barra diagonal (forward-slash). O analisador de URL WHATWG normaliza barras invertidas (backslashes) e suas formas codificadas em porcentagem para barras diagonais nos esquemas http, https, ws e wss. Consequentemente, um caminho que utiliza segmentos de ponto com barra invertida pode ignorar as verificações de travessia, permitindo que solicitações não autenticadas escapem dos prefixos pretendidos e alcancem endpoints upstream não autorizados. Isso resulta em um impacto de confidencialidade e impacto limitado de integridade.

Uma aplicação que utiliza o plugin CORS para o framework web Fastify pode travar durante uma requisição de preflight CORS se o plugin for registrado com a opção de hook `onSend` não padrão. Quando uma requisição OPTIONS contendo os cabeçalhos Origin e Access-Control-Request-Method é recebida, o plugin chama `reply.send()` de dentro do hook `onSend`, fazendo com que os cabeçalhos de resposta sejam gravados duas vezes. Isso resulta em um erro ERR HTTP HEADERS SENT não capturado que pode encerrar o processo Node.js caso não haja um manipulador de nível de processo instalado. Um cliente remoto não autenticado pode disparar esse estado com uma única requisição de preflight, impactando a disponibilidade do sistema.

Existe um problema onde o plugin não propaga um erro de análise para o fluxo de arquivo quando o corpo de uma requisição termina dentro de uma parte de arquivo sem um limite de fechamento, desde que o Content-Length esteja completo, o cliente não aborte e nenhum limite de tamanho de arquivo seja excedido. Isso faz com que o plugin destrua o fluxo de arquivo em andamento sem um erro. Consequentemente, manipuladores que realizam trabalho assíncrono antes de consumir o arquivo conectam-se a um fluxo que nunca emite um evento de erro ou de término, deixando a requisição sem resposta enquanto a conexão permanece aberta. Um cliente remoto não autenticado pode explorar isso enviando uploads malformados repetidamente para esgotar os recursos do servidor, levando a um Denial of Service (DoS), uma condição onde um serviço fica indisponível para seus usuários pretendidos.

Quando configurado com a opção de cookie assinado, o plugin não interrompe o processamento quando a verificação de assinatura reporta um valor inválido. Em vez disso, ele passa o valor original do cookie para o decodificador de sessão, permitindo que uma sessão com assinatura inválida seja descriptografada. Isso ocorre se uma aplicação utilizar um segredo de assinatura de cookie separado da chave de criptografia de sessão e rotacionar apenas o segredo de assinatura. Um invasor que possua um cookie de sessão criptografado e não expirado pode remover a assinatura obsoleta para continuar usando a sessão. O invasor não pode forjar dados de sessão, estender a expiração ou contornar a rotação da chave de criptografia.

A validação de destino normaliza barras invertidas literais antes de decodificar a porcentagem do caminho da solicitação. Isso permite que um caminho contendo barras invertidas codificadas e segmentos de ponto ignore a verificação de segmento de ponto. Se o servidor upstream tratar a barra invertida como um separador de caminho, a solicitação encaminhada pode escapar do prefixo de proxy configurado para acessar locais irmãos no upstream. Um invasor remoto não autenticado pode explorar isso para recuperar recursos fora do prefixo pretendido, impactando a confidencialidade.

Quando uma aplicação utiliza prefixos parametrizados e opções `rewritePrefix` para fixar clientes a um caminho upstream fixo, o plugin substitui parâmetros de rota decodificados de URL no `rewritePrefix` sem reencodificá-los. Um invasor remoto não autenticado pode fornecer um valor de parâmetro que codifica um separador de caminho junto com um delimitador de fragmento ou consulta. Isso é decodificado em separadores e delimitadores reais que injetam segmentos de caminho upstream adicionais e removem o sufixo obrigatório que o `rewritePrefix` deveria impor. Isso permite que o invasor acesse locais upstream fora do prefixo pretendido, resultando em bypass de restrição de caminho, o que pode levar a server-side request forgery (SSRF) ou bypass de autorização no serviço proxy.

Um problema de negação de serviço ocorre quando o servidor é configurado com um `handlerTimeout` diferente de zero e uma rota retorna uma resposta de streaming. Se o stream de uma requisição permanecer aberto além do tempo limite após o envio dos cabeçalhos, o servidor tenta enviar uma nova resposta de erro. Isso dispara uma exceção `ERR HTTP HEADERS SENT` não capturada, que encerra o processo Node.js e interrompe todas as outras requisições ativas. Um cliente remoto não autenticado pode acionar isso enviando uma única requisição para um endpoint de streaming afetado.

Quando a opção não padrão `ignoreDuplicateSlashes` está ativada, o plugin associa o middleware do Express com escopo de caminho a uma URL onde a normalização de barras duplicadas colapsa o separador após o esquema de um alvo de solicitação em forma absoluta. Isso faz com que o roteador do Fastify resolva a solicitação para o caminho com escopo e execute o manipulador, enquanto a camada do Express não reconhece mais esse caminho. Como resultado, um invasor não autenticado pode usar um alvo em forma absoluta para alcançar um manipulador em uma rota com escopo, como um caminho de administrador, ignorando o middleware de autenticação, autorização ou limitação de taxa.

Com o comportamento padrão de sessão rotativa, uma requisição que restaura uma sessão antes de um logout pode salvar sua própria cópia após outra requisição ter completado a chamada de destruição da sessão. Isso permite a recriação de um identificador de sessão destruído juntamente com seus dados autenticados. Um invasor que possua um cookie de sessão assinado válido de uma vítima pode manter uma requisição em trânsito durante o logout e repetir esse cookie para restaurar a sessão após ela ter sido revogada, sem a necessidade de roubo de cookies ou falsificação de assinatura.

Existe uma condição de corrida no analisador multipart quando configurado com uma função `fileFilter()` assíncrona. Se uma requisição for abortada enquanto um `fileFilter()` assíncrono ainda estiver pendente, o callback pode retomar um fluxo de análise que já foi encerrado. Isso faz com que o analisador subjacente emita um erro em um fluxo que não possui mais um ouvinte de erro, resultando em um evento de erro não tratado que interrompe o processo do Node.js, levando a uma Negação de Serviço. Este problema afeta qualquer aplicação que utilize um `fileFilter()` assíncrono, independentemente do mecanismo de armazenamento utilizado.

Quando uma entrada de proxy é configurada para encaminhar WebSockets, o servidor encaminha solicitações de upgrade de WebSocket não-HMR (Hot Module Replacement) para o alvo do proxy sem validar os cabeçalhos Host ou Origin. Isso ignora a proteção allowedHosts. Consequentemente, uma página web maliciosa visitada por um desenvolvedor pode estabelecer uma conexão WebSocket de origem cruzada através do servidor de desenvolvimento para ler e gravar no backend proximado, mesmo que o servidor esteja vinculado ao endereço de loopback.

Existe um problema onde uma única requisição pode travar qualquer aplicação que utilize as opções padrão. Quando uma requisição utiliza um Content-Encoding como gzip, o software a direciona para um fluxo de descompressão, mas não anexa um ouvinte de erro após a leitura do corpo. Se a carga útil contiver um quadro comprimido válido seguido de bytes residuais, a aplicação responde normalmente ao quadro válido, mas os bytes residuais acionam um erro no decodificador finalizado. Esse erro é relançado como uma exceção não capturada, encerrando o processo. Como a análise do corpo ocorre antes do roteamento, qualquer endpoint que analise um corpo é afetado.

O endpoint 'open-editor' não autenticado valida o cabeçalho Host usando uma expressão regular projetada para esquemas de Origem de navegador. Um valor de Host começando com `file:` ou um esquema de extensão pode ignorar as verificações de hostname e `allowedHosts`. Um peer de rede pode enviar uma requisição com um Host malformado que passa na validação, fazendo com que a construção da URL do endpoint falhe. No modo padrão de não produção, o servidor retorna uma resposta HTTP 500 contendo o rastreamento completo da exceção (stack trace), o que revela caminhos absolutos do sistema de arquivos, locais de módulos instalados e números de linhas internas do código-fonte.

As funções `normalize()` e `serialize()` aplicam incorretamente a remoção de segmentos de ponto da RFC 3986 ao caminho de uma referência de caminho relativo. Esse algoritmo é definido apenas para o caminho de destino mesclado durante a resolução. Consequentemente, um segmento de diretório pai inicial pode ser removido, fazendo com que uma referência relativa ao documento se torne relativa à raiz. Aplicações que normalizam referências relativas fornecidas por usuários antes da resolução, ou que as utilizam como chaves de cache, deduplicação ou autorização, podem permitir que a referência escape de seu diretório pretendido e aponte para um recurso diferente.