Komyunghan

Existe uma condição de corrida no processo de rotação de tokens de atualização (refresh-token). Isso ocorre porque o arquivo `UserRefreshToken.ts` não verifica a contagem de linhas afetadas durante a rotação. Consequentemente, um invasor que tenha capturado um token de atualização pode apresentá-lo simultaneamente ao usuário legítimo para estabelecer uma sessão autenticada válida sem que um evento de reutilização seja registrado.

Uma falha de autorização existe no processo de criação de integração dentro do arquivo `integrations.service.ts`. Especificamente, a lógica de cópia descriptografa as credenciais de conexão de uma integração de origem sem verificar o proprietário ou a sinalização de status privado. Usuários autenticados com a função de Creator podem explorar isso fornecendo identificadores de integração adivinhados ou enumerados para copiar hosts de banco de dados, nomes de usuário e senhas privados de outros usuários para uma integração que eles controlam.

O gerenciamento inadequado de privilégios em `org-users.service.ts` permite que a atualização da função de organização legada de um usuário reescreva sua função `default-workspace`. Isso permite que usuários revogados recuperem silenciosamente acesso de nível Criador para leitura, gravação e modificação de esquema em todas as bases do `default-workspace` usando seu token de sessão existente.

Existe um problema de autorização incorreta onde tokens de API com escopo de base funcionam como credenciais de conta global. Isso ocorre porque o `base id` associado ao token não é armazenado nem verificado. Consequentemente, um invasor que possua um token vazado pode ler, gravar e excluir registros em todas as bases das quais o proprietário do token é membro, incluindo aquelas ingressadas após a criação do token.

Verificações de permissão insuficientes no nível da rota e a ausência de validação de espaço de trabalho ou propriedade no serviço de suporte permitem que usuários autenticados com baixos privilégios ou aqueles com uma chave de API válida acessem ou excluam o histórico de upsert do armazenamento de documentos de outros usuários e espaços de trabalho. Isso ocorre quando o `chatflowId` de destino (exposto publicamente em links de compartilhamento) ou os IDs de linha são conhecidos. O problema envolve os endpoints "GET /api/v1/upsert-history/:id" e "PATCH /api/v1/upsert-history", especificamente nas funções `getAllUpsertHistory()` e `patchDeleteUpsertHistory()`. A função `getAllUpsertHistory()` retorna linhas com base em um `chatflowid` fornecido por um invasor, enquanto a `patchDeleteUpsertHistory()` exclui linhas usando um array de UUIDs de registro fornecido por um invasor. Os dados expostos nos campos `flowData` e `result` podem incluir configurações de nós de embedding, gerenciador de registros e vector-store, incluindo `paramValues` por nó.

A validação insuficiente da propriedade do `organizationId` nas rotas de escrita e exclusão de banco de dados permite que usuários com a função de construtor (builder) realizem ações não autorizadas em bancos de dados pertencentes a outras organizações. Devido à ausência de guardas de resolução de organização, um invasor pode criar, modificar ou excluir permanentemente tabelas e esquemas entre limites de locatários (tenants) em instâncias compartilhadas.

Existe um problema onde a associação à organização não é validada nas rotas de leitura do banco de dados. Isso permite que qualquer usuário autenticado acesse esquemas de tabela e dados de linha pertencentes a outras organizações. Um invasor pode fornecer IDs de organização arbitrários em parâmetros de URL para listar tabelas, recuperar definições de colunas e executar consultas de junção para ler dados armazenados de organizações vítimas.

O Budibase contém uma configuração incorreta de autorização no nível de rota, onde o endpoint "PUT /api/datasources/:datasourceId" é incorretamente atribuído ao grupo `authorizedRoutes` com permissões `TABLE/READ` em vez do grupo `builderRoutes`. Isso permite que qualquer usuário autenticado com a função integrada `BASIC` ou superior envie solicitações para reescrever o objeto `config` de uma fonte de dados, incluindo o `host`, `port`, credenciais do banco de dados ou a `url` base de uma fonte de dados REST. Como as conexões de driver SQL carecem de proteção contra Server-Side Request Forgery (SSRF)—uma técnica onde um invasor força um servidor a fazer solicitações para um local não pretendido—o redirecionamento de uma fonte de dados PostgreSQL, MySQL ou MongoDB para um endereço IP interno permite que um invasor sonde ou interaja com serviços internos em portas arbitrárias. Além disso, isso pode ser usado para interromper o serviço ao injetar configurações inválidas, causando uma Negação de Serviço (DoS) para todas as consultas da aplicação que dependem dessa fonte de dados.