Steffen Deusch

Ocorre Cross-site Scripting (XSS) quando um invasor controla nomes de atributos, permitindo a injeção de atributos e scripts no HTML renderizado através da função `Phoenix.HTML.attributes escape/1`. A função `key escape/1` não neutraliza adequadamente espaços em branco em chaves binárias, permitindo a criação de novos atributos, como manipuladores de eventos. Além disso, chaves do tipo atom são apenas dasherizadas, permitindo a passagem de caracteres como aspas e colchetes angulares. Este problema afeta aplicações que constroem chaves de atributos a partir de entradas não confiáveis e as renderizam usando HEEx `<tag {@attrs}>`, `content tag/3` ou chamadas diretas. Chaves aninhadas `data`, `aria` e `phx` também são suscetíveis. Isso pode levar à execução de scripts arbitrários nos navegadores dos usuários que visualizam as páginas afetadas.

Um problema de Redirecionamento Aberto (Open Redirect) existe onde um invasor pode redirecionar o navegador de uma vítima para uma origem arbitrária. Isso ocorre porque a função `redirect/2` utiliza `validate local url!/2` para garantir que o destino seja um caminho local, mas falha ao não rejeitar caracteres de tabulação ASCII, LF ou CR. Como os navegadores removem esses caracteres antes de analisar a URL, um valor como `/<TAB>/example.com` ignora a validação e é interpretado como uma URL relativa ao esquema. A função `push patch/2` também é afetada em versões anteriores a 0.7.0. O problema é acionado quando a aplicação passa um valor influenciado externamente como o parâmetro `:to`, como um parâmetro `return to` durante o login ou um destino de navegação de um payload `handle event/3`.

Um problema de cross-site scripting existe no phoenix live view devido à validação inadequada do esquema de URL. As funções `valid destination!/2` e `valid live navigation destination!/2` utilizam um auxiliar interno `uri scheme/1` que não detecta esquemas se a entrada começar com um espaço ou um caractere de controle ASCII. Como os navegadores padrão removem esses caracteres iniciais antes da análise, um invasor pode fornecer um payload como " javascript:alert(1)" que ignora a validação e é tratado como um caminho relativo seguro. Quando renderizado via `<.link href={...}>`, o navegador executa o script na sessão da vítima. Isso afeta aplicações que renderizam URLs fornecidas pelo usuário, como alvos de redirecionamento ou links de perfil.

Um invasor não autenticado pode causar a negação de serviço em qualquer endpoint que monte um socket Phoenix com um transporte de canal acessível, como WebSocket ou LongPoll. O problema reside na rotina `Elixir.Phoenix.Socket`:handle in/4 dentro do arquivo lib/phoenix/socket.ex. Como os transportes do Phoenix não limitam o número de canais que um único processo de transporte pode ingressar, um cliente pode enviar um número ilimitado de mensagens phx join através de uma única conexão. Isso gera processos de canal excessivos, podendo esgotar o limite máximo de processos do BEAM e impedir que a máquina virtual inicie novos processos para tráfego legítimo. Essa amplificação ocorre dentro de uma única conexão, tornando ineficazes os limites de conexão e a limitação de taxa na camada de rede.

O cliente JavaScript Presence no phoenix contém uma verificação inadequada de condições excepcionais que permite que um invasor com acesso comum ao canal cause uma negação de serviço persistente no lado do cliente para todos os visualizadores de um tópico de canal de presença. O problema reside no arquivo `assets/js/phoenix/presence.js` dentro das rotinas `Presence.syncState()` e `Presence.syncDiff()`. O cliente utiliza um teste de verdade simples (`state[key]`) em vez de uma verificação de propriedade própria para verificar se uma presença existe. Como as chaves de presença são controladas pelo invasor, um usuário pode fornecer uma chave que corresponda a um nome de membro do `Object.prototype` (como ` proto `, `constructor`, `toString` ou `hasOwnProperty`). Isso faz com que a busca retorne o `Object.prototype` integrado em vez de `undefined`, levando o código a tentar ler `.metas.map(...)` do protótipo, o que gera um `TypeError` não capturado. Essa exceção impede que o estado local seja atualizado e evita que o `onSync()` seja disparado. Como o servidor continua a enviar a chave maliciosa, a sincronização permanece interrompida para todos os visualizadores do tópico até que o invasor saia. Trata-se de uma confusão de tempo de leitura do objeto protótipo e não de poluição de protótipo.