Infinit3I

Existe um problema onde a função `SAML.verifySamlResponseSignature` chama `OpenSAML SignatureValidator.validate` sem antes aplicar o `SAMLSignatureProfileValidator`. Isso permite que o sistema aceite uma assinatura criptograficamente válida que referencia um elemento XML diferente da Resposta ou Asserção usada para autenticação. Um invasor pode mover um elemento assinado dentro do documento e fornecer um elemento de identidade malicioso, resultando em XML Signature Wrapping, o que permite a autenticação como outro usuário do provedor de identidade. Isso afeta os caminhos de assinatura em nível de resposta e de asserção, e permanece acessível durante o login iniciado pelo SP, mesmo que o `allowIDPInitiatedLogin` esteja desativado.

Existe um problema na função `SAML.handleCallback()` onde ela não consome o RelayState, não registra identificadores de asserção ou não impõe o `Response.InResponseTo`. Em fluxos iniciados pelo Provedor de Serviço (SP), um invasor com uma resposta SAML válida e o RelayState correspondente pode resubmetê-los ao endpoint `/recipe/saml/callback` antes da expiração da asserção. Em fluxos iniciados pelo Provedor de Identidade (IdP), as asserções podem ser repetidas sem o RelayState. Além disso, a falta de verificações de `Response.InResponseTo` permite que um login em andamento seja concluído com uma asserção de uma identidade diferente e ignora a configuração `allowIDPInitiatedLogin=false`. O callback também não valida o Destination ou SubjectConfirmationData Recipient e NotOnOrAfter, resultando na criação de um novo código de autorização para a identidade do usuário capturado.

Um problema de SQL injection existe na interface de administração do Mautic no endpoint '/s/ajax'. O problema ocorre porque um parâmetro de requisição usado para selecionar o campo de contato para pesquisa não é devidamente validado antes de ser incluído em uma consulta ao banco de dados. Qualquer usuário autenticado, independentemente de sua função ou permissões atribuídas, pode explorar isso usando técnicas cegas—como métodos baseados em booleano ou tempo—para executar consultas SQL arbitrárias. Isso permite que o invasor leia informações sensíveis do banco de dados, incluindo contas de usuário, endereços de e-mail, hashes de senha, dados de contato e conteúdo de campanhas.

Existe um problema onde o modelo `ApplicationModel.ts` aceita um identificador de autorização de aplicativo escolhido pelo chamador. O endpoint 'applications/:id/confirm' vincula esse identificador a um usuário logado por meio de uma página de consentimento genérica. Subsequentemente, o endpoint público 'packages/server/src/routes/api/application auth.ts' passa esse identificador para a função `createAppPassword()` sem autenticar ou vincular o resgatador. Isso permite que um invasor engane uma vítima para aprovar um identificador malicioso, obtenha um ID e senha de aplicativo duráveis e troque essas credenciais por uma sessão com acesso total de leitura e gravação aos dados sincronizados da vítima.

Existe um problema na função `host port()` em `adminer/include/functions.inc.php` onde a string de login `server` é analisada incorretamente. O grupo de captura de porta exige dígitos ancorados ao final da string; se um valor de servidor contiver um sufixo não numérico, a regex falha e a string inteira é retornada como o host com uma porta vazia. Isso permite que um invasor remoto não autenticado ignore a restrição de portas privilegiadas em `adminer/include/auth.inc.php` ao enviar um valor manipulado, como `127.0.0.1:80/x`. Consequentemente, o cliente mysqli/mysqlnd reanalisa o host e a porta, permitindo a falsificação de requisição do lado do servidor (SSRF) e a varredura cega de portas internas ao observar as respostas de conexão (conexão recusada, handshake ou timeout) antes que as credenciais sejam validadas.

O software prefixa o cabeçalho `X-Forwarded-Prefix` fornecido pelo cliente ao `$ SERVER["REQUEST URI"]` sem realizar uma verificação de proxy confiável ou validar o valor do prefixo. Um invasor pode fornecer uma URL absoluta através do cabeçalho `X-Forwarded-Prefix`, que é então incorporada aos cabeçalhos de redirecionamento Location, ao atributo de caminho Set-Cookie e a links autorreferenciais. Isso permite um redirecionamento aberto autenticado após requisições POST de alteração de estado, controle não autenticado do atributo de caminho do cookie de sessão e o envenenamento de links autorreferenciais. O desmembramento de cabeçalhos (header splitting) e o Cross-Site Scripting (XSS) não são possíveis, pois caracteres de Retorno de Carro/Alimentação de Linha (CR/LF) não podem ser injetados.

Um problema de server-side request forgery (SSRF) existe no validador do campo de servidor do formulário de login. O validador verifica apenas inteiros iniciais para portas privilegiadas e não rejeita valores de porta não numéricos. Isso permite que atacantes injetem chaves PDO DSN, como `host=` e `port=`, no parâmetro `server` para ignorar as restrições de portas privilegiadas e estabelecer conexões TCP com hosts e portas internos arbitrários antes da autenticação.

Uma correção incompleta na guarda de validação dentro de `bootstrap.inc.php` permite que certos valores no cabeçalho `X-Forwarded-Prefix` ignorem as verificações de segurança. Embora o sistema bloqueie prefixos que iniciam com `//`, ele permite valores onde o segundo caractere é uma barra invertida, como `/evil.com`. Como os navegadores normalizam barras invertidas para barras normais, essa referência de caminho de rede persiste no `REQUEST URI` e atinge a função `cookie path()`, afetando o atributo Path do Set-Cookie. Este problema pode ser explorado se os clientes puderem definir o cabeçalho `X-Forwarded-Prefix`, geralmente devido a um proxy reverso ausente ou mal configurado, resultando em um escopo anômalo do caminho do cookie.