Mcollina

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 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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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 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.

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.

O software realiza a decodificação de percentagem do componente de esquema usando a função global legada `unescape()` antes da validação. Isso permite que entradas com esquemas codificados em percentagem sejam emitidas como esquemas ativos, contrariando a RFC 3986. Aplicações que filtram esquemas perigosos na entrada bruta, mas armazenam ou renderizam o resultado normalizado, podem inadvertidamente permitir a criação de URLs executáveis de `javascript`, `data` ou `vbscript`, resultando em cross-site scripting armazenado ou refletido. Além disso, a função `equal()` trata esquemas codificados e simples como idênticos, o que pode ser usado para burlar listas de permissões baseadas em igualdade.

Quando as funções `serialize()`, `normalize()` ou `resolve()` são chamadas com a opção `reference` (não padrão) definida como `suffix` em uma referência sem autoridade, a referência relativa emitida pode conter dois pontos simples não escapados em seu primeiro segmento de caminho. Isso viola a RFC 3986, pois faz com que a string seja reanalisada como uma URI absoluta com um esquema. Consequentemente, um aplicativo que trate o resultado como uma URI pode transformar entradas inertes em URLs ativas de `javascript`, `data` ou `vbscript`, criando um vetor de cross-site scripting. Além disso, a função `equal()` pode confundir uma referência com esquema com uma relativa. A exposição é limitada a aplicações que utilizam a opção de referência `suffix` não padrão.

A função `use()` une o caminho de montagem de um middleware com escopo de caminho ao prefixo de escopo do plugin de uma forma que pode divergir do caminho servido pelo roteador do Fastify. Isso ocorre principalmente quando o prefixo do escopo termina em uma barra, quando caminhos de montagem em array são usados ou quando caminhos de montagem são escritos sem uma barra inicial. Quando os dois caminhos divergem, o middleware é silenciosamente ignorado enquanto o manipulador de rota ainda é executado, permitindo que uma única requisição não autenticada ignore middlewares de escopo de caminho, como autenticação, autorização ou limitação de taxa.

Para esquemas da família HTTP, a função `canonicalizeHost()` passa o host analisado para o analisador de URL WHATWG e adota seu hostname sem verificar se o analisador consumiu toda a entrada como um host. Isso permite que a autoridade seja silenciosamente reescrita, descartando dados antes de um sinal de arroba (@) e removendo caracteres de tabulação, retorno de carro e alimentação de linha sem reportar erro. Aplicações que aplicam políticas baseadas em host, como listas de negação, filtragem de loopback, validação de redirecionamento ou roteamento de proxy de saída, podem observar que o host canônico diverge da representação verificada, permitindo que o tráfego seja direcionado para um destino indesejado.