Pesquisadores de segurança alertam que muitas organizações têm instâncias do código Apex inseguro em suas implantações do Salesforce, o que dá margem a vulnerabilidades graves e pode levar ao vazamento ou corrupção de dados que colocam os negócios em risco.
Apex é uma linguagem de programação orientada a objetos com tipologia forte, cuja sintaxe é semelhante à linguagem Java que os desenvolvedores podem usar para executar instruções de fluxo e controle em servidores Salesforce em conjunto com chamadas por meio da API do Salesforce. Ela permite que os usuários personalizem suas instâncias do Salesforce adicionando lógica de negócios aos eventos do sistema, incluindo cliques em botões, atualizações de registros relacionados e páginas do Visualforce.
Pesquisadores da empresa de segurança Varonis relataram ter encontrado vulnerabilidades de gravidade alta e crítica no código Apex usado por várias empresas da lista Fortune 500 e agências governamentais, mas alertam que práticas inseguras semelhantes são provavelmente comuns em organizações de todos os tamanhos e de todos os setores.
“Se exploradas, as vulnerabilidades podem levar ao vazamento de dados, corrupção de dados e danos às funções de negócios no Salesforce”, disseram os pesquisadores em um relatório. “É por isso que é vital acompanhar as classes do Apex e suas propriedades, quem pode executá-las e como são usadas.”
De acordo com a documentação do Salesforce, o código Apex pode fazer chamadas de linguagem de manipulação de dados (DML), fazer consultas Salesforce Object Query Language (SOQL) e Salesforce Object Search Language (SOSL) para retornar listas de registros sObject, realizar processamento em massa de vários registros ao mesmo ao mesmo tempo, ser usado para criar chamadas de API públicas personalizadas a partir de métodos Apex armazenados e muito mais.
Isso torna as classes Apex uma ferramenta poderosa para desenvolvedores, mas também muito importante para revisar cuidadosamente suas capacidades e restringir quem pode acessá-las. O código Apex pode ser executado em dois modos: “sem compartilhamento”, em que o código Apex ignora as permissões do usuário e pode acessar qualquer registro e confirmar alterações, e “com compartilhamento”, cujo código respeita as permissões no nível do registro do usuário, mas ignora o nível do objeto. e permissões em nível de campo.
Às vezes, as classes Apex configuradas para execução no modo “sem compartilhamento” são necessárias para implementar funcionalidades importantes, mas podem se tornar um risco sério, especialmente quando são disponibilizadas para convidados ou usuários externos. Alguns dos tipos mais comuns de problemas que podem derivar das classes Apex são referências diretas a objetos (IDOR) inseguras, que podem permitir que um invasor leia, manipule ou exclua tabelas completas de dados aos quais não deveria ter acesso, ou injeção de SOQL ; e injeção SOSL onde o código apresenta falhas que permitem que invasores manipulem as consultas feitas pela classe para exfiltrar dados ou alterar o fluxo de processo pretendido.
Embora os pesquisadores não tenham descrito cada vulnerabilidade em detalhes, o relatório inclui um exemplo de prova de conceito em que um invasor com acesso de convidado abusa de uma classe excessivamente permissiva para acessar um valor secreto de um campo personalizado nos registros de outros usuários.
Veja isso
Vulnerabilidades críticas no Salesforce, Windows e Cloudflare
Hackers exploraram dia zero da Salesforce para atacar Facebook
Os pesquisadores da Varonis incentivam as organizações a revisar quem pode chamar as diferentes classes Apex usadas em suas instâncias e seus recursos, especialmente classes executadas no modo “sem compartilhamento”. Isso pode ser feito manualmente, passando por cada aula, mas é um processo demorado.
O relatório da Varonis também inclui práticas recomendadas sobre como proteger o código Apex para evitar entradas inseguras que podem levar à injeção de SOQL ou SOSL. Com base no modelo de responsabilidade compartilhada, são os clientes do Salesforce e não o Salesforce que são responsáveis pela segurança de seu código Apex. “Uma estratégia de segurança abrangente deve verificar se as classes Apex foram revisadas por especialistas em segurança, não apenas por desenvolvedores e administradores do Salesforce”, disseram os pesquisadores.
Para ter acesso ao relatório completo da Varonis, em inglês, sobre as vulnerabilidades do código Apex em implantações do Salesforce clique aqui.
