Pascal Knoth

**Nome do Software Vulnerável e Versões Afetadas** boruta versões 2.3.0 a 2.3.6 **Description** Existe uma falha de bypass de autenticação que permite a um invasor autenticar-se como um cliente OAuth utilizando uma asserção de cliente JWT anteriormente válida, mas expirada. O software aceita os métodos de autenticação `client secret jwt` e `private key jwt` no endpoint de token, mas não verifica se a claim `exp` está no futuro. Especificamente, a função `check expiration/1` em `Boruta.Oauth.Request.Base` apenas verifica a presença da claim `exp`, e a função `token config/0` em `Boruta.Oauth.Authorization.Client.Token` retorna um mapa vazio, ignorando o validador de expiração padrão. Um invasor que obtenha uma asserção de cliente assinada através de logs ou proxies pode reproduzi-la indefinidamente para obter tokens de acesso com os privilégios do cliente. **Recommendations** Atualize o boruta para a versão 2.3.7 ou posterior. Restrinja o uso da autenticação `client secret jwt` e `private key jwt` a clientes altamente confiáveis. Prefira métodos de autenticação não baseados em JWT, como `client secret basic` ou `client secret post`. Emita asserções de cliente de curta duração e proteja-as contra exposição em logs de aplicação, proxies frontais, ferramentas de navegador e sistemas de observabilidade.

**Nome do Software Vulnerável e Versões Afetadas** malach-it Boruta versões 2.3.2 até 2.3.6 **Description** Um invasor remoto não autenticado pode fazer com que o servidor de autorização OAuth/OpenID emita requisições HTTP externas para URIs arbitrárias, incluindo serviços internos e endpoints de metadados de nuvem. Isso ocorre porque três caminhos de código buscam URIs remotas fornecidas pelo solicitante sem a validação suficiente. Especificamente, a função `fetch unsigned request/1` desreferencia o parâmetro `request uri`, a função `parse registration params/2` desreferencia a `jwks uri` fornecida em uma requisição de registro dinâmico de cliente OpenID Connect, e a função `refresh jwk from jwks uri/1` atualiza a `jwks uri` armazenada para um cliente existente. A validação é insuficiente, pois apenas verifica se a URI é analisada com um esquema, falhando em exigir HTTPS, impor listas de permissão de host ou IP, rejeitar intervalos de IP de loopback ou privados após a resolução de DNS, limitar o tamanho da resposta ou restringir redirecionamentos. **Recommendations** Atualize o malach-it Boruta para a versão 2.3.7 ou posterior. Restrinja o egresso de rede do host Boruta para evitar que o servidor de autorização OAuth/OpenID alcance endereços de loopback, privados, link-local, multicast ou de metadados de nuvem. Desative as rotas da aplicação para a desreferenciação de `request uri` do OAuth e o registro dinâmico de clientes OpenID Connect, ou restrinja o registro dinâmico de clientes a chamadores confiáveis.

**Nome do Software Vulnerável e Versões Afetadas** boruta versões 2.3.0 a 2.3.6 **Description** Isolamento ou Compartimentação Imprópria no módulo `Elixir.Boruta.Openid` permite que invasores não autenticados registrem clientes OpenID Connect com privilégios administrativos através do ponto de entrada de registro dinâmico de clientes. A função `register client/3` encaminha parâmetros fornecidos pelo chamador para o caminho de criação de cliente administrativo sem uma lista de permissões (allowlist) de nível de campo. Isso permite que invasores definam atributos sensíveis de segurança, como tipos de concessão suportados, escopos autorizados, imposição de PKCE, comportamento de atualização e revogação pública, tempos de vida de token e configurações de assinatura. O problema também está associado à função `parse registration params/2`. A falha ocorre porque a biblioteca não distingue entre os metadados que um registrante público pode definir e os controles administrativos que exigiriam a aprovação de um operador. **Recommendations** Atualize o boruta para a versão 2.3.7. Desative a rota de registro dinâmico de clientes ou restrinja-a a administradores autenticados. Se o registro dinâmico precisar permanecer disponível para chamadores não confiáveis, evite encaminhar os parâmetros da requisição diretamente para `register client/3`; em vez disso, construa um mapa de parâmetros contendo apenas metadados públicos definidos pelos padrões e sobrescreva os atributos administrativos com valores de um perfil de servidor de privilégio mínimo fixo antes de chamar a função.