- Navios
- 23 de setembro de 2026 às 01:50 UTC
- Autor
- Kamo
- Enviar
- 9060c7c
Três descobertas independentes, fixadas juntas porque os dois primeiros compartilham arquivos e uma classe. 1. O AiMcpController tinha zero controlos de direita sobre o create/update/delete/test — qualquer membro assinado do a organização poderia instalar uma configuração de servidor MCP, e Mcp-gateway-service do mcpStdioTransport executa config.command com config.envVars como um processo operacional real (novo ProcessBuilder(...).start(), no início do portal e novamente em cada 30s exame de saúde. Isso é RCE não autenticado contra Mcp-porta-serviço. Cada manipulador de mutações/teste agora requer MANAGEM AI SETTINGS, correspondente AiProviderController, e STDIO é recusado diretamente para uma configuração criada pela organização — uma O locatário só pode configurar SSE/HTTP. (ai mcp server configs tem 0 linhas; nenhuma migração necessária.) 2. SSRF: **************** enviou a chave do provedor descriptografada de uma organização para qualquer host estava na baseUrl e refletiu a resposta, e OpenAiCompatívelAdapter (que não tinha nenhuma regra de acolhimento em nenhuma das suas três chamadas de saída — incluindo o caminho de bate-papo real que cada mensagem leva, não apenas o botão de teste manual. Adicionado OutboundUrlGuard, construído sobre a biblioteca existente da Kamo-shared-Biblioteca PublicHostGuard (já utilizada pela SecurityService SafeSiteFetcher e SafeImageFetcher para a mesma classe de problema): resolve o anfitrião e recusa ************* endereços e apenas nomes de cluster (*.svc, *.cluster.local, dotless), verificados no tempo de poupança em AiProviderController e AiMcpController e novamente imediatamente antes de cada chamada OpenAiCompatívelAdapter, uma vez que a resposta DNS de um hostname em tempo de economia não é sua resposta para sempre. Recusa é um 400 simples com nossa própria mensagem — nenhuma exceção de rede bruta, e nenhuma conexão é Nunca tentou um destino recusado. 3. * **************** UserId) Querited registros de uso e então, incondicionalmente, voltou verdadeiro — cada pedido AiAccessPolítica / limite token era decorativo. A dois sites de chamadas reais (ChatOrchestrationService's streaming and sync chat paths) agora resolvem cada papel que o membro detém e impõe a política mapeada de cada papel: um papel sem subvenções políticas mapeadas sem restrições próprias, mas também não pode anular uma política restritiva o papel diferente que um membro também desempenha. A sobrecarga de 2 arg desperdiçada desapareceu. Testes: AiMcpControllerAuthzTest (direitos + recusa de DSTIO + validação de url), OutboundUrlGuardTest, AiProviderKeyExposiçãoTeste (2 novos casos SSRF), ************* AcessoPolíticaMultiRoleTest. Cada caso foi verificado vermelho contra o código pre-fix antes deste commit (direitos de não-abertura, confiança no corpo, não-operação e controlos de quotas sempre verdadeiros, cada reintroduzido localmente, um de cada vez, e restaurado após a confirmação do teste de correspondência falhou). mcp-gateway-service obtém um commit correspondente: uma STDIO allowlist independente (defesa em profundidade, em Caso esta verificação seja sempre ignorada) e a sua própria verificação antes da ligação no url de uma configuração SSE/HTTP.