Yordis Prieto

Uma alocação de recursos sem limites ou controle permite a negação de serviço (DoS) através da criação ilimitada de átomos a partir de entradas binárias influenciadas por um invasor. O módulo `Guardian.Plug.Keys` deriva chaves de namespace de conexão e sessão passando binários arbitrários para a função `String.to atom/1`. Especificamente, a função `base key/1` em `lib/guardian/plug/keys.ex` converte binários em átomos, e as funções auxiliares `claims key/1`, `resource key/1` e `token key/1` criam átomos adicionais. Da mesma forma, `key from other/1` converte binários capturados por regex através de `String.to atom/1`. Pontos de entrada de alto nível, como `Guardian.Plug.current token(conn, key: key)`, passam chaves fornecidas pelo chamador diretamente para essas funções. Como `String.to atom/1` cria um novo átomo para cada binário não visto e os átomos não são coletados pelo garbage collector, a tabela de átomos do BEAM (que possui um limite padrão de aproximadamente 1.048.576 entradas) pode ser esgotada. Se uma aplicação rotear dados não confiáveis, como um identificador de locatário ou cabeçalho de requisição, para uma chave Guardian através do parâmetro `key`, um invasor pode enviar um fluxo de entradas variadas para consumir a tabela de átomos e travar o nó BEAM, afetando todas as aplicações executadas nele.

Uma alocação de recursos sem limites ou controle permite a negação de serviço (DoS) através da criação ilimitada de átomos a partir de entradas binárias controladas por um invasor. O codificador `Guardian.Permissions.AtomEncoding` processa escopos de permissão passando binários arbitrários para a função `String.to atom/1`. Quando a função `encode/3` em `lib/guardian/permissions/atom encoding.ex` é chamada com uma lista, a cláusula binária `encode value/3` chama `String.to atom(value)` sem uma verificação de lista de permissões, descartando o argumento `perm set`. Como a função `String.to atom/1` cria um novo átomo para cada binário não visto e os átomos não são coletados pelo garbage collector, a tabela de átomos do BEAM (limitada a aproximadamente 1.048.576 entradas) pode ser esgotada. Um invasor que forneça entradas variadas através de corpos de requisição ou claims de JWT pode causar a falha do nó BEAM por `system limit`, derrubando todas as aplicações executadas nele.

Uma alocação de recursos sem limites ou controle no módulo `Guardian.Permissions` permite a negação de serviço via exaustão da tabela de átomos do BEAM. O mixin `Guardian.Permissions` instala uma função pública `encode permissions!/1` que chama `String.to atom(to string(k))` para cada chave de um mapa fornecido antes da validação. Na função `do encode permissions!/2`, a cláusula de valor inteiro ignora a validação contra o conjunto de permissões configurado, permitindo que chaves com valores inteiros sejam internadas como novos átomos. Como os átomos não são coletados pelo garbage collector e a tabela de átomos do BEAM possui tamanho fixo, um invasor que consiga influenciar um mapa de permissões passado para `encode permissions!/1` ou `encode permissions into claims!/2` pode exaurir a tabela, derrubando o nó BEAM e todos os serviços em execução. Este problema está associado ao arquivo `lib/guardian/permissions.ex` e às funções `encode permissions!/1`, `encode permissions into claims!/2` e `do encode permissions!/2`.

A verificação inadequada de assinaturas criptográficas permite que um invasor não autenticado revogue a sessão de uma vítima usando um token forjado. A função `Guardian.revoke/3` em `lib/guardian.ex` utiliza `peek/1` para decodificar tokens, o que realiza apenas a decodificação base64 do cabeçalho e do payload do JWT, sem verificar a assinatura. Essas reivindicações não verificadas são então encaminhadas para o callback de revogação do módulo de token e para o callback `on revoke`, que podem alterar o estado. Um invasor que conheça ou adivinhe valores de reivindicação identificadores, como `jti` ou `sub`, pode forjar um JWT e enviá-lo para endpoints que utilizam `Guardian.revoke/3`, resultando em uma negação de serviço onde a sessão legítima da vítima é removida. Isso ocorre quando o módulo de token altera o estado com base nessas reivindicações, como em exclusões de lista branca ou inserções em lista negra.

O manuseio inadequado de dados altamente comprimidos permite a negação de serviço por meio de uma bomba de descompressão em corpos de resposta HTTP. Quando `Tesla.Middleware.DecompressResponse` ou `Tesla.Middleware.Compression` é utilizado em um pipeline de middleware, os corpos de resposta são descomprimidos de forma ávida sem limite de tamanho. A função `decompress body/2` passa o corpo completo da resposta para `:zlib.gunzip/1` ou `:zlib.unzip/1` sem limitar o tamanho da saída. Além disso, a função `compression algorithms/1` divide o cabeçalho `content-encoding` por vírgulas, e a `decompress body/2` recursa para cada token. Um servidor que anuncie múltiplos tokens gzip no cabeçalho `content-encoding` pode desencadear passagens de descompressão recursivas, resultando em amplificação exponencial de dados, onde uma pequena carga útil de rede expande-se para gigabytes de BEAM heap (área de memória utilizada pela máquina virtual Erlang), esgotando a memória e travando ou congelando o processo de chamada.

A codificação ou escape inadequado de saída permite a injeção de cabeçalho de parte multipart por meio de valores de parâmetro `Content-Disposition` não escapados. A função `part headers for disposition()` interpola parâmetros de disposição sem validar caracteres de retorno de carro (`r`), alimentação de linha (` `) ou aspas duplas. Esses valores são recebidos do chamador via `add field()` (parâmetro `name`), `add file()` (parâmetro `filename`) e `add file content()` (parâmetro `filename` e outras opções de disposição). Um caractere de aspas duplas pode fechar prematuramente um parâmetro citado, enquanto sequências `r ` podem encerrar o cabeçalho `Content-Disposition` para iniciar um novo cabeçalho forjado ou encerrar o bloco de cabeçalhos para prepender bytes ao corpo da parte. Além disso, o caminho do nome de arquivo padrão em `add file()` utiliza `Path.basename()`, que não remove retornos de carro ou alimentações de linha.

O manuseio inadequado da distinção entre maiúsculas e minúsculas em `Tesla.Middleware.FollowRedirects` permite o vazamento de credenciais para origens de terceiros em redirecionamentos de origem cruzada. O middleware tenta remover cabeçalhos sensíveis comparando-os com uma lista de filtros em letras minúsculas contendo `authorization` e `host`. No entanto, como o Tesla preserva as chaves dos cabeçalhos exatamente como fornecidas pelo chamador, sem normalização, cabeçalhos que utilizam a capitalização canônica, como `Authorization`, não coincidem com o filtro em minúsculas e são encaminhados para o destino do redirecionamento. Um atacante que possa controlar a resposta `Location:` — por meio de seu próprio endpoint, um upstream de redirecionamento aberto ou uma origem comprometida — pode capturar tokens de portador ou outros materiais de autorização. Isso ocorre quando a aplicação utiliza `Tesla.Middleware.FollowRedirects` e define cabeçalhos com chaves que não estejam em letras minúsculas.

A neutralização inadequada de sequências CRLF (Carriage Return e Line Feed) em cabeçalhos HTTP permite a injeção de cabeçalhos HTTP. A função `Tesla.Multipart.add content type param/2` anexa strings fornecidas pelo chamador à lista `content type params` multipart sem validar caracteres `r` ou ` `. Posteriormente, a função `Tesla.Multipart.headers/1` une esses parâmetros textualmente para construir o valor do cabeçalho Content-Type de saída. Um parâmetro contendo `r ` divide a linha do cabeçalho, permitindo que cabeçalhos arbitrários sejam injetados na solicitação HTTP de saída. Qualquer aplicação que encaminhe entradas não confiáveis, como charset ou strings de parâmetros fornecidas pelo usuário, para a função `Tesla.Multipart.add content type param/2` é afetada. Isso pode resultar na falsificação de cabeçalhos de solicitação de saída ou potencial contrabando de requisições (request smuggling) contra o servidor upstream.

Um problema no Tesla.Adapter.Mint permite a negação de serviço via exaustão da tabela de átomos. A função `open conn/2` converte o esquema de URL de requisições de saída em um átomo BEAM usando `String.to atom(uri.scheme)` sem validação de lista de permissões. Átomos BEAM são entradas permanentes que não são coletadas pelo garbage collector e são limitadas a uma tabela de aproximadamente 1.048.576 entradas. Um invasor capaz de influenciar a URL da requisição — por meio de recursos de encaminhamento de URL no nível da aplicação, como webhooks, proxies ou importadores, ou via um cabeçalho Location quando o `Tesla.Middleware.FollowRedirects` está ativo — pode criar um novo átomo para cada requisição variando a string do esquema. Quando a tabela de átomos fica cheia, a máquina virtual falha, resultando no desligamento completo da aplicação.