James Harton

Um problema de fixação de sessão permite que um invasor mantenha uma sessão autenticada se conseguir plantar um identificador de sessão no navegador de uma vítima antes que ela faça login. Isso ocorre porque a função `store in session/2` em `AshAuthentication.Plug.Helpers` utiliza `Plug.Conn.put session/3` para gravar o sujeito autenticado sem chamar `Plug.Conn.configure session(renew: true)`, fazendo com que o identificador de pré-autenticação persista. Isso afeta a função padrão `success/4` em `AshAuthentication.Phoenix.Controller. using /1`, o `AuthController` de `mix ash authentication phoenix.install` e o auto-login de lembrete (remember-me). Além disso, a função `clear session/2` utiliza `Plug.Conn.clear session/1`, que remove o conteúdo da sessão, mas mantém o identificador, permitindo que um ID plantado sobreviva a um ciclo de logout e login. Em implantações que utilizam armazenamento de sessão no servidor (como ETS, Mnesia, Redis ou banco de dados), isso pode levar ao controle total da conta. Isso é possível se o invasor conseguir plantar um cookie via cookie tossing de um subdomínio irmão, um host HTTP sem HSTS ou um navegador compartilhado.

A expiração insuficiente de sessão permite que uma sessão revogada permaneça totalmente autenticada. Quando um recurso é configurado com `session identifier :jti` e `require token presence for authentication?` está desativado, o valor da sessão é armazenado como `<jti>:<subject>`. As funções `AshAuthentication.Plug.Helpers.authenticate resource from session/4` e `AshAuthentication.Phoenix.LiveSession.on mount/4` utilizam `split identifier/2` para descartar o `jti` e passar apenas o subject para `AshAuthentication.subject to user/3`. Como o registro de revogação não é consultado, o estado de revogação e a expiração do `jti` são ignorados, permitindo que sessões capturadas antes do encerramento da sessão permaneçam ativas.

Uma falha de autenticação inadequada permite que um invasor acesse a conta de outro usuário ao vincular uma identidade OAuth2 a uma conta que não lhe pertence. A função `AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3` localiza uma conta existente usando chaves `upsert identity` e valida o vínculo através de `email trusted?/2`. No entanto, essa verificação apenas lê o booleano `email verified` do provedor e não compara o valor do e-mail do provedor com o e-mail da conta correspondente. Essa falha também ocorre em `OAuth2.SignInPreparation` quando `registration enabled?` é falso e a conta é localizada pelo filtro de leitura da ação de login. Um invasor com um e-mail verificado em um provedor pode obter uma sessão para uma conta correspondida por outro atributo. Além disso, o processo sobrescreve o e-mail da conta correspondente para o endereço do invasor, permitindo que este intercepte futuras tentativas de recuperação de conta.

Existe uma falha de bypass de autenticação por spoofing na estratégia `dynamic oidc`. Isso permite que um invasor que utilize uma conexão de provedor de identidade seja autenticado como um usuário local estabelecido por meio de uma conexão diferente. O problema ocorre porque o isolamento de namespace de identidade pretendido, que deveria formatar o campo `strategy` das linhas `UserIdentity` como `"<name>/<connection id>"`, não é aplicado. Em vez disso, a variável ` connection id ` é populada apenas em uma estrutura de tempo de execução efêmera e não é utilizada durante o processo de alteração de identidade na função `DynamicOidc.IdentityChange.change/3`. Consequentemente, o sistema retorna ao nome da estratégia simples para gravações e leituras de identidade em `oauth2/user resolver.ex` e `oauth2/sign in preparation.ex`. Como a chave única do recurso de identidade é `(uid, strategy)` e o sistema não processa a reivindicação `iss` (issuer), usuários de provedores diferentes com o mesmo valor `sub` (subject) são tratados como o mesmo usuário. Isso pode resultar no sequestro de contas sem interação da vítima ou na fusão silenciosa de usuários distintos que compartilham o mesmo identificador de assunto em provedores diferentes.

Uma falha de bypass de autenticação por spoofing permite que um atacante substitua a sessão autenticada de uma vítima por sua própria conta ao plantar um cookie remember-me no navegador da vítima. Isso ocorre porque a função `sign in using remember me/3` verifica a sessão em busca de uma chave `<subject name> token` para evitar a reautenticação de usuários já logados. No entanto, a função `store in session/2` grava essa chave apenas quando `require token presence for authentication?` está habilitado; caso contrário, grava apenas o nome do sujeito. Nas configurações padrão, o guardião lê uma chave que nunca é gravada, fazendo com que o processo de login remember-me seja executado em cada requisição. Consequentemente, um cookie plantado é aceito mesmo que exista uma sessão ativa, levando a vítima a inserir dados inadvertidamente em uma conta controlada pelo atacante. Essa discrepância ocorre porque o caminho de leitura em `authenticate resource from session/4` seleciona a chave corretamente, enquanto o guardião não o faz.

A verificação inadequada de assinaturas criptográficas no AshAuthentication permite que um chamador da ação de revogação de token neutralize uma revogação ou escreva linhas arbitrárias no recurso de token. A função `AshAuthentication.TokenResource.RevokeTokenChange.change/3` lê o argumento `:token` e o decodifica usando `AshAuthentication.Jwt.peek/1`, que delega para `Joken.peek claims/1` sem realizar a verificação de assinatura. Consequentemente, as claims `jti`, `exp` e `sub` são gravadas diretamente no registro de revogação. Um invasor pode fornecer um token forjado com uma claim `exp` retroativa, fazendo com que a linha de revogação seja tratada como expirada e removida por `expunge expired`, o que permite que o token genuíno passe na verificação `revoked?`. Além disso, valores arbitrários de `jti` e `sub` podem ser inseridos no recurso.

Uma autenticação inadequada permite que um invasor com um token de login para um recurso autenticado seja autenticado como um usuário de um recurso diferente. A função `extract primary keys from subject/2` em `AshAuthentication.Strategy.Password.SignInWithTokenPreparation` analisa a reivindicação `sub` do JWT usando `URI.parse/1` e mantém apenas a string de consulta, descartando o segmento de caminho que identifica o sujeito para o qual o token foi emitido. Como `AshAuthentication.Jwt.verify/3` valida apenas a assinatura e reivindicações específicas (`exp`, `nbf`, `jti` e versão da biblioteca) sem restaurar a vinculação do recurso, e os nomes dos campos de chave primária são idênticos entre os recursos, a autenticação é burlada. Este comportamento também afeta as preparações de login WebAuthn e remember-me. O caminho de login por link mágico não é afetado.

Um problema no AshAuthenticationPhoenix permite que um invasor com acesso a logs de acesso, logs de proxy ou histórico do navegador recupere um token de login de uso único e se autentique como o proprietário do token. Isso ocorre porque o `AshAuthentication.Phoenix.Components.Password.SignInForm` constrói o caminho `sign in with token` usando o `user. metadata .token` como um parâmetro de consulta e realiza um redirecionamento GET. Consequentemente, o token é registrado na linha de requisição por servidores web, proxies reversos e histórico do navegador, expondo uma credencial ativa em locais que são tipicamente menos seguros que o armazenamento de sessão.

A expiração insuficiente da sessão permite que um invasor que obtenha o valor `state` do OAuth2 de uma vítima repita o callback e autentique essa vítima em uma conta controlada pelo invasor. A função `AshAuthentication.Strategy.OAuth2.Plug.callback/2` não limpa os `session params` armazenados durante caminhos de falha, como quando o provedor retorna um erro de acesso negado, um código inválido ou um erro de troca de token. Como o bloco `else` na cadeia `with` do Elixir atinge `store authentication result/2` mantendo a conexão original, a entrada da sessão não é removida. Consequentemente, o valor destinado a proteger contra Cross-Site Request Forgery (CSRF) é consumido apenas quando a autenticação é bem-sucedida e persiste após tentativas canceladas ou malsucedidas.

Uma falha de bypass de autorização permite que um invasor autenticado sobrescreva e confirme o endereço de e-mail de outro usuário para assumir o controle da conta. Isso ocorre porque um token de confirmação emitido para um usuário é aceito no registro de qualquer outro usuário. Especificamente, a função `AshAuthentication.AddOn.Confirmation.ConfirmChange` verifica a assinatura do token e sua claim `act`, mas não compara a claim `sub` com `changeset.data` antes de aplicar as alterações ao registro de destino. Um invasor pode registrar uma conta, alterar seu próprio e-mail e repetir o token resultante contra o ID do registro de uma vítima usando `force change attributes/2` para definir seu próprio endereço e carimbar `confirmed at`, obtendo acesso posteriormente via redefinição de senha. O fluxo de confirmação que utiliza `AshAuthentication.AddOn.Confirmation.Actions.confirm/3` não é afetado, pois resolve corretamente `sub` para um usuário.

O AshAuthentication permite a divulgação de digests de senhas de usuários para leitores do armazenamento de auditoria. O add-on `audit log` constrói o `extra data` de cada entrada na função `AshAuthentication.AddOn.AuditLog.Auditor.build extra data/4`, que recebe o `:actor` do contexto de callback da ação literalmente. Quando uma ação auditada é invocada com `actor:` definido como um registro de usuário, esse registro—incluindo o atributo `hashed password`—é depositado na entrada de auditoria. Embora outras identidades sejam reduzidas via `AshAuthentication.user to subject/1` e os parâmetros sejam filtrados, o ator permanece sem filtragem. Definir o atributo `sensitive?: true` não é eficaz, pois redige apenas a saída de `inspect/1` e não a codificação JSON ou o armazenamento de termos brutos. A exploração requer acesso de leitura independente ao armazenamento de auditoria (ex: credenciais de banco de dados, backups ou transportadores de log), permitindo ataques de senha offline contra contas ativas. A persistência desses dados depende da camada de dados; armazenamentos de termos brutos os mantêm literalmente, enquanto armazenamentos SQL podem descartar a entrada, a menos que o recurso de usuário derive `Jason.Encoder`.

O AshAuthentication apresenta um problema onde leitores do armazenamento de auditoria podem recuperar endereços IP de clientes que o modo de privacidade `:hash` do add-on de log de auditoria deveria pseudonimizar. A função `hash ip/1` calcula um `:crypto.hash(:sha256, salt <> ip)` não chaveado e trunca o resultado para 16 caracteres hexadecimais. O salt é recuperado das chaves de configuração de aplicativo `:audit log ip salt` ou `:secret`; no entanto, ele assume a string constante "default-salt-change-in-production" se nenhuma for definida, sem emitir um aviso. Como o espaço de endereços IPv4 é limitado a 2^32 valores e o SHA-256 é computacionalmente eficiente, a tabela de hash pode ser pré-computada, permitindo que os valores armazenados sejam mapeados de volta aos seus endereços de origem. Este risco persiste mesmo com um salt configurado caso o salt seja vazado, pois o hash continua sendo barato de enumerar.

Um problema de complexidade algorítmica ineficiente permite que um invasor não autenticado cause exaustão de CPU e memória ao enviar uma chave de API com um segmento base62 excessivamente grande. A função `AshAuthentication.Base.decode62/1` em `lib/ash authentication/base.ex` processa argumentos dividindo-os em binários por caractere e utilizando `charval62/2`, que recomputa `Integer.pow(62, index)` em cada posição. Isso resulta em um crescimento cúbico no custo em relação ao comprimento da entrada. Adicionalmente, a função `bindecode62/1` apresenta crescimento quadrático devido ao uso de `Integer.undigits/2` e `Integer.digits/2`. Como o `AshAuthentication.Strategy.ApiKey.SignInPreparation` processa segmentos separados por sublinhado da chave enviada sem limitar o `byte size/1` ou exigir autenticação prévia, o sistema fica suscetível à exaustão de recursos que não pode ser mitigada pelas cláusulas de resgate existentes.

Ocorre uma condição de corrida de Tempo de Verificação ao Tempo de Uso (TOCTOU) quando um link mágico é configurado com `single use token?`. Isso permite que um invasor com um link mágico vazado repita um token de uso único e se autentique como o sujeito alvo. O problema surge porque a verificação de validade do token não é serializada em relação ao seu consumo, permitindo que resgates simultâneos tenham sucesso e gerem tokens de usuário completos. O processo de login verifica o JWT usando `Jwt.verify/4` e o revoga posteriormente via `AshAuthentication.Strategy.MagicLink.SignInPreparation` em um callback `Query.after action` e `AshAuthentication.Strategy.MagicLink.SignInChange` em um hook `after transaction`. Como `AshAuthentication.TokenResource.Actions.revoke/3` executa a revogação como um upsert, revogações duplicadas simultâneas ocorrem com sucesso sem conflitos.

Uma falha de bypass de autenticação permite que usuários não confirmados obtenham uma sessão, ignorando os requisitos obrigatórios de confirmação de e-mail. O problema ocorre na função `check user/2` dentro de `AshAuthentication.Strategy.Password.Actions`, que utiliza `is nil(Map.get(user, value))` para verificar o atributo especificado por `require confirmed with`. Se o atributo não for selecionado ou for negado por uma política de campo, `Map.get/2` retorna `%Ash.NotLoaded{}` ou `%Ash.ForbiddenField{}` em vez de `nil`, levando o sistema a tratar incorretamente o usuário como confirmado. Além disso, a verificação `require confirmed with` é executada apenas dentro de `AshAuthentication.Strategy.Password.Actions` e não nas próprias ações. Consequentemente, chamadores que invocam as ações diretamente, como `AshGraphql` ou `AshJsonApi`, ignoram completamente a verificação de confirmação em configurações padrão.

Um invasor não autenticado pode forjar entradas de log da aplicação ao enviar uma identidade de redefinição de senha contendo quebras de linha ou caracteres de controle. A função `AshAuthentication.Strategy.Password.RequestPasswordReset.run/3` interpola a variável `identity`, que contém o e-mail ou nome de usuário da solicitação de redefinição, em heredocs de `Logger.warning/1` sem escape, truncamento ou restrição de tipo. Como uma quebra de linha na variável `identity` encerra o registro de log, qualquer texto subsequente é gravado como uma nova linha, permitindo que um invasor manipule a tag de severidade e o conteúdo das entradas para que pareçam ter sido originadas pela aplicação.

Uma autenticação inadequada permite que JSON Web Tokens (JWTs) com finalidade limitada sejam reutilizados como credenciais completas de API bearer quando um recurso utiliza verificação de token bearer sem estado. A função auxiliar `retrieve from bearer/3` verifica a assinatura de um JWT Authorization: Bearer e rejeita tokens que contenham uma reivindicação `act`, mas não verifica se a reivindicação `purpose` do token é igual a `user`. Quando o recurso é configurado com `require token presence for authentication?` definido como `false`, a função `validate token/3` retorna `{:ok, nil}` sem consultar o recurso de token, ignorando as verificações de finalidade subsequentes. Como resultado, JWTs válidos e não expirados emitidos para finalidades restritas — como o token `sign in` emitido pelo WebAuthn ou pela estratégia de Password — são aceitos como credenciais bearer de propósito geral, resultando em uma atribuição completa de `current user`. Um invasor que obtenha um token `sign in` válido pode se autenticar como o sujeito alvo, ignorando a semântica de uso único e revogação. Isso requer que a aplicação utilize `retrieve from bearer/3` em uma rota acessível e empregue WebAuthn ou a estratégia de Password com `sign in tokens enabled?` definido como `true`.

Ocorre cross-site scripting (XSS) refletido quando uma estratégia é configurada com `require interaction?` definido como true. O software exibe páginas HTML intermediárias que incorporam parâmetros de requisição diretamente em atributos de valor de entrada oculta sem a devida codificação HTML. Especificamente, o parâmetro `confirm` é interpolado em `lib/ash authentication/add ons/confirmation/confirmation form.html.eex` e o parâmetro de token de link mágico é interpolado em `lib/ash authentication/strategies/magic link/sign in form.html.eex`. Como esses templates utilizam expressões simples que não realizam a codificação e as funções `accept/2` em `AshAuthentication.AddOn.Confirmation.Plug` e `AshAuthentication.Strategy.MagicLink.Plug` não validam os valores, um invasor não autenticado pode criar uma URL para injetar marcações maliciosas. O script injetado é executado na origem da aplicação, permitindo o acesso a cookies, sessões e respostas de mesma origem.

Uma falha de bypass de autenticação por spoofing permite a invasão de contas de usuários locais durante o login via OAuth2 ou OIDC. O problema ocorre porque o software associa usuários locais pelo endereço de e-mail em vez de utilizar a combinação de claims `iss` (issuer) e `sub` (subject) do OpenID Connect, que são os únicos identificadores estáveis e únicos para um usuário final. Um invasor não autenticado pode registrar uma conta em um provedor OAuth aceito usando o e-mail de uma vítima — incluindo e-mails não verificados ou reutilizados — para obter privilégios locais totais da conta da vítima.

The issue affects the ash authentication phoenix library, where session tokens remain valid on the server after a user logs out. This creates a security gap where compromised tokens can continue to work, even after the user logs out. The sessions stored in the database still expire, limiting the duration during which this could be exploited. Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices. However, changing one's password does invalidate all other sessions. This may cause compliance issues with security frameworks requiring complete session invalidation.