- Navios
- 23 de setembro de 2026 às 03:08 UTC
- Autor
- Kamo
- Enviar
- 6f10239
Os webhooks da RingCentral foram processados com verificação zero: WebhookController roteou os eventos de telefonia/mensagem de loja diretamente para **************************** **************************** foi `retorno true; // TODO', e as assinaturas foram criadas sem verificaçãoToken De todo. O desfecho é público. Qualquer um que postou uma carga trabalhada poderia injetar um texto em qualquer org, forjar eventos de conformidade STOP/START, acionar um popup de chamada de entrada para um número arbitrário (toll-fraud adjacente), ou spoof "de" conteúdo mostrado para um membro — e a resolução de to-number (`findByFromPhoneNumber`) nunca foi uma org, assim que o número de um cliente real poderia ser combinado e mostrado ao inquilino errado Mesmo por uma carga genuína. Corrigir: - RingCentralWebhookProvisioner agora gera uma verificação aleatória por instalaçãoToken (persistido em config json, editado a partir da API de configurações), registra assinaturas em uma URL por instance (`?instanceId=`, equipas correspondentes/JustCall), e envia o token Então o RingCentral volta a ecos como 'Verification-Token' cabeçalho em cada notificação. Assinatura própria da RingCentral Aperto de mão de propriedade de URL (o cabeçalho 'Validation-Token' WebhookController já echoes back) é intocado — que é um cabeçalho diferente provando uma coisa diferente. Agora verifica o cabeçalho em constante tempo e falhas fechadas (sem token ainda, sem cabeçalho, ou uma incompatibilidade todos os recusar). - WebhookController resolve a instância de `?instance Id=`, requer a Verificação-Token verificação para passar, e só então processa o evento — escopo para essa instância é org. ******************* e Ambos ganharam um parâmetro OrgId verificado: corresponde em uma org DIFERENTE que o webhook verificado é tratado como Como um número que ninguém tem, nunca confiou. - Implantar a segurança (as 3 instâncias RingCentral vivas não podem perder o tráfego de entrada): cada passagem do RingCentralWebhookProvisioner agora reconcilia a conta real lista de assinaturas — uma subscrição pré-fixa (sem instânciaId/token) é substituído por um verificado, então as instâncias ao vivo se curam dentro de ~30s do novo pod se tornando líder (já é executado na inicialização + a cada 12h). Para a lacuna anterior que cura completa, WebhookController ainda aceita um evento sem instânciaId de acordo com as regras pré-fixas, não abrangidas — mas apenas até 2026-10-13, e cada Usa troncos altos. linha para que o recuo seja visível e não permanente. Depois dessa data ele falha fechado como todo o resto. Relatório para o coordenador: nenhuma ação necessária para as 3 instâncias vivas do RingCentral — curam automaticamente na próxima implantação. Em termos operacionais, Em voipservice logs depois desta implantação. parar de aparecer em poucos minutos. Se ainda estiver próximo de 2026-10-13, descubra porque é que a subscrição dessa instância não foi curada (falhas do ringcentralJwtTokenService são registrados separadamente) antes da cutover, ou estender **************************** Ensaios: **************************** (falhas fechadas sem token/header/ token errado, aceita o token correspondente, cabeçalho insensível à caixa), **************************** (gera+persists+reusa o token; apaga a pré- fixar assinatura e registra uma substituição verificada; deixa uma corrente saudável subscrição exclusiva), mais casos de org-scoping adicionados ao VoipCallEventService Ensaio e VoipMessageServiceKeywordTest. Todas as quatro mutações verificadas: revertendo o guarda torna o teste correspondente vermelho, restaurando-o torna-o verde.