5Ud0Er

O formulário de perfil expõe a permissão `only assigned tickets` aos proprietários que não são administradores. A função `UsersController::profileSave()` permite a adição ou remoção de `User::PERM ONLY ASSIGNED TICKETS` sem verificar se o editor possui privilégios de administrador. Consequentemente, um agente restrito pode remover restrições impostas pelo administrador ao desmarcar a opção ou enviar um salvamento de perfil que a omita, permitindo-lhe ler e modificar conversas atribuídas a outros agentes em qualquer caixa de correio da qual seja membro.

Um usuário autenticado com baixos privilégios pode explorar a mutação GraphQL `createOrUpdateUserIntegration` em `crates/services/user/src/integration operations.rs` ao fornecer o `integrationId` de outro usuário para a função `create or update user integration()`. Devido à ausência de uma verificação de propriedade, o SeaORM trata a chave primária fornecida como um alvo de atualização, atribuindo o `user id` do chamador e substituindo os `provider specifics` e outras configurações da integração visada. Isso permite que um invasor transfira a propriedade, sobrescreva configurações ou desative a integração de uma vítima, desde que tenha obtido o ID de integração não brute-forceable da vítima. A operação não revela valores de credenciais armazenados.

Um agente autenticado não administrador que seja membro de pelo menos uma caixa de correio pode explorar um atalho de pesquisa por número na função `search()` do `ConversationsController`. Ao solicitar o endpoint '/search' com um número de ticket prefixado por hash, o sistema resolve o número do ticket controlado pelo usuário sem aplicar o filtro de caixa de correio ou a política de visualização exigidos. Isso permite que o agente use o cabeçalho 302 Location para confirmar a existência de uma conversa em uma caixa de correio à qual não tem acesso e descobrir seus identificadores internos de conversa e pasta. Este problema não divulga conteúdo de mensagens, anexos ou dados de clientes.

Existe um problema no caminho de busca de imagem otpauth onde um nome de host é validado usando `ValidatesUrls::isExternalHost()` e, posteriormente, resolvido novamente por `IconService::storeRemoteImage()` para a requisição HTTP. Se a busca externa de imagens otpauth estiver habilitada, um usuário autenticado com controle sobre DNS autoritativo de baixo TTL pode fornecer um endereço público durante a fase de validação e um endereço interno durante a fase de conexão. Isso permite que o usuário ignore a lista de negação de endereços privados e acesse endpoints de loopback, rede privada, link-local ou metadados de nuvem.

Existe um problema onde endpoints específicos aceitam a variável `scan ports` de qualquer sessão autenticada, incluindo usuários não administradores, ou sem autenticação se o login estiver desativado. Os endpoints 'scripts/lua/rest/v2/add/host/to scan.lua' e 'scripts/lua/rest/v2/exec/host/schedule vulnerability scan.lua' utilizam a função de validação `validateSingleWord()`, que permite metacaracteres de shell. Este valor é posteriormente concatenado em um comando nmap através da função `nmap scan host()` e executado via `ntop.execCmd()` ou `ntop.execCmdAsync()` usando popen. Para os módulos tcp portscan e cve, uma sondagem preliminar nmap -sn deve reportar o alvo como ativo. Se o nmap estiver instalado, isso permite a injeção de comandos, possibilitando a execução de comandos arbitrários do sistema operacional como a conta de serviço ntopng sem interação adicional do usuário.

O endpoint GET '/api/support/v1/manage course team/' em CourseTeamManageAPIView carece de uma verificação de autorização de função de suporte global, exigindo apenas que o usuário esteja autenticado. Isso permite que qualquer aluno autenticado forneça um e-mail, nome de usuário ou `user id` para determinar se uma conta está ativa com base na discrepância entre as respostas 200 e 404. Além disso, usuários com funções de instrutor em nível de curso ou organização podem recuperar as atribuições de equipe ou instrutor de um usuário alvo dentro de seu escopo específico.

Inquilinos autenticados podem escapar do prefixo de sua chave de objeto devido a um segmento splat de nome de arquivo não sanitizado. Ao fornecer sequências `../` para os endpoints 'api/v1/packets' e 'api/v2/packets', um invasor com uma chave de API válida pode obter URLs GET ou PUT pré-assinadas para ler ou sobrescrever payloads e saídas de execução pertencentes a outros inquilinos.

O controle de acesso insuficiente na ferramenta de gerenciamento de projetos permite a recuperação não autorizada de ativos de arquivo. Os endpoints 'WorkspaceFileAssetEndpoint.get' e 'WorkspaceAssetDownloadEndpoint.get' resolvem registros de `FileAsset` sem verificar se o membro do workspace pertence ao projeto do ativo, permitindo o download de ativos de projetos privados caso o UUID do ativo seja conhecido. Além disso, o endpoint de âncora pública 'EntityAssetEndpoint.get' concede acesso `AllowAny` e limita a busca ao nível do workspace, em vez da entidade ou projeto publicado específico. Isso permite que usuários não autenticados, com uma âncora válida e um UUID de ativo, recuperem ativos de descrição de problemas ou descrição de comentários de projetos privados ou não publicados naquele workspace.

Existe um problema onde o RPC (Chamada de Procedimento Remoto) `get-page` aceita um objeto de permissão de link de compartilhamento que fornece acesso de leitura amplo, mas não verifica se o `page-id` solicitado está entre as páginas autorizadas pelo link. Um invasor autenticado que possua um link de compartilhamento válido pode recuperar os dados completos de forma e design de outras páginas no mesmo arquivo, caso o identificador da página seja conhecido. Além disso, o RPC `get-file-fragment` permite o acesso via link de compartilhamento sem mapear corretamente os fragmentos para as páginas autorizadas.

A falta de validação do nível de acesso em mutation resolvers permite que membros com acesso de apenas leitura ao projeto realizem ações não autorizadas. Este problema afeta 26 de 29 procedimentos de mutação, permitindo que usuários modifiquem, excluam e publiquem dados do projeto. Especificamente, invasores podem excluir relatórios e painéis, agendar a exclusão de projetos inteiros, publicar análises privadas em links de compartilhamento público e modificar regras de alerta.

Os procedimentos de busca de compartilhamento falham ao validar os controles de acesso, permitindo que chamadores não autenticados recuperem definições de relatórios protegidos e hashes de senha argon2id. Atacantes com um link de compartilhamento podem obter configurações completas de relatórios, incluindo filtros, nomes de eventos e dimensões de detalhamento, o que pode levar ao roubo de inteligência de negócios e quebra de senhas offline.

O importador de dados falha ao não utilizar a proteção contra SSRF do projeto, utilizando em vez disso um mecanismo de fetch simples para recuperar URLs fornecidas pelo usuário. Na função `parseRemoteFile()` em `packages/importer/src/providers/umami.ts`, a variável `config.fileUrl` é validada apenas como uma string de URL, permitindo requisições para endereços internos como `http://127.0.0.1:9911/` ou `http://169.254.169.254/latest/meta-data/`. Um membro autenticado da organização pode explorar isso para forçar o servidor a se conectar a qualquer endereço alcançável. O servidor então retorna o status HTTP e o texto do status via `import.get`, criando um oráculo de varredura para hosts, portas e caminhos internos. Além disso, se uma resposta interna estiver formatada como um CSV do Umami, os dados são ingeridos como eventos e tornam-se visíveis nas visualizações de análise do invasor. SSRF (Server-Side Request Forgery) é uma falha onde um invasor força um servidor a fazer requisições para um local não pretendido.

O endpoint de pesquisa de compartilhamento público não aplica os controles `shareCredentials` e `shareHiddenFromTree`. O endpoint autoriza apenas a nota ancestral fornecida na requisição e realiza uma pesquisa de texto completo em toda a subárvore publicada, retornando o título, o identificador de compartilhamento e o caminho hierárquico das notas correspondentes sem verificar se a nota individual requer senha ou está oculta. Um visitante não autenticado pode usar este endpoint como um oráculo booleano—um sistema que fornece uma resposta sim/não a uma consulta—para confirmar substrings arbitrárias e recuperar o conteúdo completo de notas compartilhadas e protegidas.

Um usuário autenticado com acesso ao projeto pode recuperar o histórico de alterações de componentes restritos por meio de endpoints de alteração de API aninhados. Isso ocorre porque esses endpoints aninhados não aplicam as verificações de acesso ao nível de componente exigidas para as visualizações diretas de componentes, permitindo a enumeração de alterações de componentes que deveriam estar ocultos. Os dados expostos podem incluir a identidade do componente restrito, links de tradução e unidade, e campos de carga de alteração, como o conteúdo da string de origem ou traduzida nos valores `target`, `old` e `details`.

Usuários autenticados podem realizar server-side request forgery (SSRF) ao enviar URLs manipuladas. Este problema ocorre na função `fetch url()` da classe `ScenarioImport`, permitindo que atacantes façam requisições HTTP arbitrárias. Isso pode ser utilizado para sondar serviços de rede interna, enumerar portas através de assinaturas de erro e acessar endpoints de metadados de nuvem para recuperar credenciais sensíveis.

Aplicações Astro SSR que utilizam páginas de erro pré-renderizadas, como '/404' ou '/500' com `export const prerender = true`, buscam essas páginas via HTTP em tempo de execução quando ocorre um erro. A URL da busca é derivada de `request.url`, que obtém sua origem do cabeçalho `Host` recebido. Quando o cabeçalho `Host` não é validado contra `allowedDomains`, um invasor pode direcionar a busca para um host arbitrário e ler a resposta. Isso ocorre especificamente em implantações SSR que utilizam `createRequestFromNodeRequest` de `astro/app/node` com `app.render()` sem a sobreposição de `prerenderedErrorPageFetch`.