Dizconnectz

Quando a configuração `limit user customer visibility` está ativada, a ação AJAX `load customer info` realiza uma busca global usando um e-mail de cliente fornecido pelo usuário e verifica apenas se o agente tem acesso a uma caixa de correio especificada. Isso permite que um agente não administrador recupere o perfil renderizado de um cliente não relacionado ao especificar uma caixa de correio à qual tenha acesso, ignorando a verificação `CustomerPolicy::view()`. Os dados expostos podem incluir nomes, endereços de e-mail, números de telefone, informações de empresa e cargo, endereços postais, perfis sociais, sites e notas internas confidenciais do agente.

O endpoint de login 'POST /api/token' lê o campo `email` do corpo da requisição sem validar o tipo e o passa diretamente para uma consulta do MongoDB. Se o campo `email` for fornecido como um tipo não string, como um objeto JSON, a função `parseWhere()` no adaptador de armazenamento MongoDB descarta o campo, resultando em um filtro vazio que corresponde a todos os usuários. O sistema então valida a senha fornecida em relação ao primeiro usuário retornado, que geralmente é o administrador do site. Isso leva a um bypass de autenticação parcial onde o identificador de e-mail é removido para a conta do administrador, permitindo a enumeração de usuários e a amplificação de credential-stuffing, já que um invasor pode testar senhas contra a conta do administrador sem conhecer seu e-mail.

O endpoint anônimo `POST /forms/{formId}/submissions` armazena `JsonData` controlado por um invasor após verificar apenas se o JSON está bem formado. Um objeto de arquivo contendo os campos `name`, `type` e `content` pode incluir uma URL HTTP ou HTTPS. Quando um membro da equipe com a permissão `submissions.view` chama o endpoint `POST /forms/{formId}/submissions/{submissionId}/files`, o `GetFilesHandler` passa os dados armazenados para a função `SubmissionFileExtractor`, que utiliza `HttpClient.GetAsync` sem validar a URL de destino, o host ou os endereços IP resolvidos em relação a intervalos de endereços internos. Isso permite requisições GET do lado do servidor, de segunda ordem e armazenadas, para serviços internos, metadados de nuvem, endereços de loopback e link-local. Para que isso ocorra, o formulário deve ter `IsPublic` e `IsEnabled` definidos, e as submissões anônimas devem passar no reCAPTCHA v3, se configurado. A resposta é incluída em um arquivo ZIP para o visualizador da equipe, em vez de ser retornada ao invasor, tornando a divulgação cega ou indireta.

Inquilinos autenticados podem explorar uma falsificação de solicitação do lado do servidor (SSRF) cega ao configurar uma URL de canal de alerta de webhook não validada. O servidor do webapp não valida a variável `url` em relação a uma lista de permissões de hosts ou lista de bloqueio de IPs privados, permitindo que o servidor envie solicitações POST para hosts internos, endereços de metadados de nuvem ou acesse o IMDSv1 via redirecionamentos. Isso ocorre quando o `alertsWorker` usa o `DeliverAlertService` para enviar payloads de alerta assinados com HMAC via função `fetch()`. O problema está enraizado no arquivo `ApiAlertChannelPresenter.server.ts`, onde a URL é aceita sem validação de sintaxe ou de host, e é posteriormente processada em `deliverAlert.server.ts` e `deliverErrorGroupAlert.server.ts`.

Existe um problema onde os destinos de webhook são validados apenas durante o registro e não durante o uso. A função `NoInternalUrlRule` em `backend/app/Validators/Rules/NoInternalUrlRule.php` utiliza `gethostbyname()` para rejeitar intervalos de IP privados e reservados, mas nomes de host públicos são permitidos. Durante o despacho, o `WebhookDispatchService` utiliza a URL armazenada via `spatie/laravel-webhook-server` sem revalidar o destino. Como o arquivo `backend/config/webhook-server.php` não configura as opções do Guzzle, o seguimento de redirecionamentos permanece ativado por padrão. Isso permite que um destino redirecione o servidor para um endereço de loopback, privado ou de metadados de nuvem, ou permite que um invasor altere um registro de DNS após o registro para alcançar o mesmo resultado. O `WebhookResponseHandlerService` armazena o corpo da resposta no log do webhook, que é então exposto através do endpoint `WebhookLogResource`, permitindo que o solicitante leia respostas de serviços internos. Isso afeta tanto os webhooks de eventos quanto os de organizadores.

Um problema de injeção de SQL existe no conector de fonte de dados Oracle durante o processo de busca de linha pós-gravação. O sistema falha ao escapar adequadamente os nomes de tabelas usados em identificadores. Um invasor com permissões de gravação em uma tabela que contenha aspas duplas em seu nome pode injetar comandos SQL. Esses comandos são executados com os privilégios do usuário do banco de dados da fonte de dados, permitindo que o invasor leia ou modifique dados arbitrários.

A visualização de configuração rápida, utilizada após a criação inicial de um evento, não verifica adequadamente se o usuário possui as permissões necessárias para alterar a configuração de um evento específico. Essa falha de autorização permite que um invasor envie uma requisição oportuna para realizar ações não autorizadas em eventos aos quais não tem acesso, como criar produtos e cotas, configurar transferências bancárias ou conectar uma conta Stripe.