Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
Uma campanha acompanhada pela Reco e divulgada em 12 de agosto expõe uma mudança importante na defesa de portais Salesforce. O ator chamado de City‑Forum usa uma ferramenta própria para consultar sites Experience Cloud baseados tanto no framework Aura quanto no Lightning Web Runtime (LWR), além de portais ServiceNow. A infraestrutura associada ao indicador principal existe desde março de 2025 e a atividade observada continua crescendo. Em um dos alvos, os pesquisadores registraram mais de 560 mil eventos ligados quase integralmente à enumeração Aura como usuário convidado. Esse volume não representa 560 mil vítimas nem 560 mil registros roubados; é uma contagem de eventos em um ambiente analisado e precisa ser comunicada com essa precisão.
O ponto central é mais desconfortável do que a narrativa de uma vulnerabilidade recém-descoberta. Segundo a Salesforce e a pesquisa independente, as requisições executam como o guest user persistente do site e recebem apenas o que objeto, compartilhamento, segurança de campo e configurações públicas permitem. Não há evidência publicada de quebra de autenticação ou defeito inerente à plataforma. O problema é que uma página aparentemente correta pode conviver com uma superfície de dados maior do que aquela que o administrador vê no navegador. A pergunta operacional, portanto, é: como provar que cada caminho anônimo — página, Aura, UI API, GraphQL, Apex, arquivo e autorregistro — entrega somente a informação intencionalmente pública?
Aura e LWR são superfícies distintas
Aura expõe requisições em /aura; LWR usa UI API e GraphQL. Um teste que cobre apenas um framework deixa o outro sem evidência.
O guest user define o retorno
Objeto, registros, campos, arquivos e código executado no contexto anônimo precisam ser testados como uma identidade externa real.
Logs ligam padrão e resultado
AuraRequest e Sites revelam IP, user agent, ações e varreduras de versões; o inventário de acesso mostra o que poderia ter sido lido.
Fechar o excesso sem apagar a jornada
Remova APIs e permissões dispensáveis, preserve somente casos públicos testados e monitore novamente após cada mudança.
Aura e LWR chegam aos mesmos dados por trilhas diferentes
No Aura, a ferramenta observada consulta os endpoints /aura ou /s/sfsites/aura. O passo de reconhecimento usa getConfigData para identificar objetos alcançáveis no contexto convidado; depois, getItems pagina registros dos candidatos. Essa técnica já era conhecida em campanhas anteriores, mas continua relevante porque grande parte dos portais ainda usa Aura. O sinal defensivo não é uma URL isolada: é a combinação de usuário convidado, volume, sequência de ações, objetos inesperados, IP e user agent incompatível com uso humano.
Em LWR, /aura está desativado, mas a camada de dados vive sob /webruntime/api/services/data/{versão}. A pesquisa encontrou chamadas GraphQL à UI API, inclusive uma sequência que testava versões de v56.0 a v66.0. As permissões de objeto, campo e registro ainda são aplicadas; o risco surge quando elas autorizam mais do que a jornada pública necessita. Isso desmonta duas falsas garantias: migrar para LWR não elimina o problema de autorização anônima, e um scanner que não encontra Aura não prova que o site está seguro.
Página fechada, API aberta: três controles que parecem equivalentes, mas não são
A visibilidade das páginas no Experience Builder, a permissão de sistema API Enabled do perfil convidado e a preferência Allow guest users to access public APIs controlam superfícies diferentes. A Reco alerta que remover API Enabled não fecha sozinho a UI API de LWR; a preferência de APIs públicas é o controle específico para GraphQL e UI API REST. A orientação da Salesforce recomenda desativar ambos quando não forem indispensáveis. Exigir login na navegação também não apaga o guest user, suas regras de compartilhamento nem código que ainda possa executar no contexto anônimo.
O autorregistro forma uma quarta fronteira. A campanha testou caminhos como /SiteRegister e /CommunitiesSelfReg para descobrir se um visitante poderia criar uma conta externa e alcançar permissões mais amplas. Desativar o recurso quando não há requisito é a decisão direta. Quando ele é necessário, o handler deve respeitar compartilhamento, usar o perfil mais restritivo, verificar email e impedir que dados coletados como convidado sejam usados para selecionar contas ou relações indevidas. O teste precisa cobrir o estado antes e depois do cadastro, não apenas a tela de inscrição.
Uma auditoria útil começa do zero e reconstrói cada necessidade pública
A Salesforce descreve quatro camadas sequenciais: acesso ao objeto, acesso ao registro, segurança em nível de campo e mascaramento do valor. A revisão deve partir do perfil convidado de cada site, porque cada Experience possui sua própria identidade anônima. Para cada objeto legível, registre qual componente ou processo precisa dele; quais registros devem ser públicos; quais campos são renderizados; e se anexos, atividades, usuários ou documentos entram por associação. Se não houver uma jornada e um responsável, o acesso deve ser removido antes de ser eventualmente restaurado com escopo explícito.
Testar apenas clicando em páginas não basta. Abra uma sessão sem autenticação, exercite páginas e formulários, mas também valide respostas de APIs públicas, componentes customizados, Flows e Apex que rodam para o convidado. Use dados sintéticos marcadores em sandbox para identificar qual camada deixou um campo escapar. Casos negativos são essenciais: ID de outro registro, filtro vazio, paginação ampla, campo não exibido, arquivo relacionado e erro de validação. A evidência procurada é simples de enunciar e difícil de fingir: o visitante recebe o mínimo em todos os caminhos, não apenas na interface feliz.
A caça precisa combinar indicador, comportamento e possibilidade de acesso
A Reco publicou um IP, domínio, user agent e assinaturas de requisição associados à campanha. Eles permitem uma busca inicial, mas não encerram a investigação: infraestrutura e ferramenta podem mudar. Em Event Monitoring, os tipos AuraRequest e Sites ajudam a localizar getConfigData, getItems, chamadas /webruntime/, varreduras consecutivas de versões e tentativas de autorregistro. A Salesforce recomenda observar picos de consultas, objetos que não deveriam ser públicos, origens desconhecidas e horários anormais. Event Monitoring exige Salesforce Shield ou o add-on específico para logs em nível de requisição, portanto a lacuna de licença também precisa entrar no risco residual.
Encontrar uma assinatura prova atividade, não necessariamente exfiltração; não encontrá-la prova apenas que aquele indicador não apareceu nos logs disponíveis. A investigação deve cruzar requisições com o histórico de configuração do guest user, regras de compartilhamento, FLS, preferência de APIs, arquivos e autorregistro no período. Se um objeto estava acessível, estime quais registros e campos poderiam ser consultados e preserve os logs antes da retenção expirar. Bloquear o IP reduz a pressão imediata, mas não corrige a exposição nem detecta outro endereço usando a mesma técnica.
Conclusão: acesso público é uma API de dados, mesmo quando o projeto é tratado como site
City‑Forum não muda o princípio de segurança; muda a evidência de que atacantes já automatizaram caminhos além do Aura conhecido. O plano mais seguro é inventariar cada site e framework, desativar APIs e autorregistro onde não são necessários, reconstruir o acesso convidado por jornada, testar resultados negativos e manter detecção comportamental. Quando a empresa publica um portal, ela também publica uma identidade técnica e um conjunto de contratos de dados. A revisão precisa ter dono, cadência e teste de regressão, porque uma nova página, Flow, regra ou campo pode reabrir a exposição sem alterar a aparência do portal.
