Salesforce Industry Cloud a crié de risques de configuration

Les clients du cloud de l’industrie de Salesforce peuvent facilement mal configurer leurs déploiements pour permettre aux attaquants d’accéder aux informations cryptées des clients, des données de session, des informations d’identification et des logiques commerciales, ont révélé que les chercheurs en sécurité.

La suite de cloud Salesforce Industry de solutions alignées verticales comprend une plate-forme à faible code qui fournit des outils de transformation numériques prédéfinis pour des industries spécifiques, telles que les services financiers et la fabrication.

Destiné aux non-développeurs, des outils à faible code peuvent permettre aux «utilisateurs non techniques de créer une logique qui touche les systèmes critiques et les données sensibles des clients et internes», a déclaré Aaron Costello, chef de la recherche de sécurité SaaS à Appomni, dans un rapport qui a identifié 20 risques erronés erronés.

« Mais cette autonomisation peut avoir un coût en ce qui concerne la sécurité, augmentant considérablement le risque de mauvaise configuration des clients », a noté Costello. «Cette combinaison de flexibilité et de confiance implicite signifie qu’un client se configurant un composant, ou surplombant un paramètre, peut entraîner une exposition aux données à l’échelle du système.»

Parmi les risques identifiés par Costello et Appomni figuraient:

• Composants à faible code qui n’appliquent pas les contrôles de contrôle d’accès ou ne respectent pas les champs de données cryptés par défaut
• Code de flux de travail exécutable par des utilisateurs externes ou non authentifiés
• Mécanismes de mise en cache qui peuvent conduire à des contrôles d’accès contournés
• Applications hors plate-forme mal développées qui peuvent entraîner un vol de jeton API
• Clés API sensibles et autres données intégrées directement dans des composants qui peuvent être lus sans autorisation
• Autorisations en insécurité sur les workflows enregistrés

Sur les 20 risques erronés identifiés par Appomni, Salesforce a émis des CVE et des conseils pour en empêcher cinq. Les autres ont été laissés aux clients pour éviter.

Salesforce émet cinq CVE

Les cinq CVE Salesforce publiés impliquent des problèmes découverts dans les composants des flexcards et des mappeurs de données d’Omnidodio. Salesforce a informé les clients le 19 mai des problèmes.

Flexcards, qui rapporte les données de Salesforce et des sources tierces à utiliser dans les workflows ou pour l’affichage dans les vues Web orientées avec les clients, représentent quatre des CVE:

• CVE-2025-43698: La source de données SOQL ignore la sécurité au niveau du champ (FLS), exposant toutes les données de champ pour les enregistrements.
• CVE-2025-43699: Le champ «Autorisations requis» peut être contourné en raison du chèque effectué côté client.
• CVE-2025-43700: l’autorisation «Afficher les données cryptées» n’est pas appliquée, renvoyant des valeurs en texte clair pour les données qui utilisent le cryptage classique pour les utilisateurs non autorisés.
• CVE-2025-43701: permet aux utilisateurs invités d’accéder aux valeurs pour les paramètres personnalisés.

Les mappeurs de données sont une fonctionnalité disponible en option pour les sources de données Flexcards ou en tant qu’action dans le cadre des procédures d’intégration (IPROC) pour le traitement des données côté serveur. Les mappeurs de données lisent et transforment les données en formats adaptés à une utilisation dans les API ou les objets Salesforce.

Costello a constaté que deux des quatre types de mappeurs de données – extrait et extrait de turbo – n’appliquent pas FLS par défaut et renvoient les données en texte en clair des valeurs cryptées aux utilisateurs sans autorisations pour les voir. Salesforce a attribué CVE-2025-43697 à cette question.

Risques de configuration supplémentaires

Quinze autres modèles de configuration peuvent également avoir de graves implications pour la sécurité pour les clients du cloud de l’industrie Salesforce.

Par exemple, les mappeurs de données et les métadonnées IPROC sont mis en cache à l’aide d’un mécanisme connu sous le nom de cache d’échelle pour accélérer l’exécution à l’avenir. Alors que les utilisateurs ont besoin de partage des règles configurées afin d’exécuter des mappeurs de données ou des IProcs, Costello a constaté qu’une fois mis en cache, ces composants deviennent exécutables par tout utilisateur indépendamment des autorisations.

« Malheureusement, il n’y a pas de paramètre de configuration qui permet d’utiliser le cache d’échelle tout en respectant les contrôles de sécurité du mappeur de données », a déclaré Costello. « Après des tests approfondis, y compris l’activation du paramètre omnistudio de contrôle de contrôle de contrôle de contrôle, il a été révélé que le seul moyen d’appliquer les vérifications d’autorisation pour les mappeurs de données est de désactiver complètement le cache d’échelle. »

Les procédures d’intégration ne respectent pas non plus le paramètre «Autorisation requis» ni les règles de partage d’aucun mappeur de données ou d’autres IProc qu’ils appellent dans le cadre de leurs actions. Ce comportement est documenté par Salesforce mais est extrêmement risqué, car les utilisateurs doivent seulement satisfaire le contrôle d’accès de l’IPCOC initial pour appeler tout mappeur de données ou IProc impliqué dans son flux de processus.

« Les organisations peuvent avoir des IPROC largement accessibles qui appellent des actions puissantes dans le cadre de l’idée fausse que les exigences d’autorisation de toutes les actions d’un IPROC seront évaluées pour l’utilisateur d’appel », a déclaré Costello.

Un autre risque de configuration courant implique des actions HTTP couramment utilisées dans le cadre des IPROC pour communiquer avec les API externes. Si ces API nécessitent une authentification, les organisations peuvent décider de coder les noms d’utilisateur et les mots de passe ou les jetons d’accès à l’API directement dans le corps de l’iProc. Quiconque peut exécuter un IPROC peut également voir les valeurs codées en dur stockées à l’intérieur. Dans de nombreux cas, cela inclut les utilisateurs externes ou même les utilisateurs invités qui peuvent exécuter les IPROC en mode débogage.

Flexcards et IPROCS prennent en charge un type de source de données appelé actions distantes qui permet l’exécution des classes APEX. Apex est un langage orienté objet de type Java de Salesforce pour la création d’applications sur sa plate-forme.

Lorsqu’un composant OmnistUdio tente d’exécuter une classe Apex via des actions distantes, la demande est proxie BusinessProcessDisplayController Classe Apex, qui comprend un GenericInvoke2NoCont méthode. Cette méthode ne valide pas si l’utilisateur appelant a la permission d’accéder à l’action distante.

« Cela se traduit par un contournement d’autorisation qui peut permettre aux utilisateurs internes et externes d’exécuter un code APEX puissant qui s’exécute sans partage ou n’implémente pas de mesures de sécurité telles que FLS », a déclaré Costello, ajoutant qu’il s’agit du comportement par défaut.

Une autre fonctionnalité qui peut générer une exposition aux informations sensibles est les packs de données, qui peuvent exporter et importer des composants vers d’autres instances Salesforce. Cette caractéristique laisse des artefacts sous la forme de fichiers de définition JSON qui peuvent contenir des objets dépendants tels que les IPROC qui contiennent en outre des mappers de données.

« Un utilisateur avec des droits d’accès à lecture à cet objet et des règles de partage excessivement larges auront la possibilité de télécharger les fichiers JSON du composant Data Pack qui sont stockés dans le sobject de la » pièce jointe «  », a déclaré Costello. « Notamment, comme ces pièces jointes reposent uniquement sur les vérifications d’accès sur le champ` `ID  » d’Omnidatapack, les utilisateurs n’ont besoin d’aucune autorisation au niveau du champ sur le sobject` `omnidatapack  » pour accéder à ces fichiers, uniquement des autorisations au niveau de l’objet et partageant le niveau de règle. »

Les packs de données peuvent également devenir orphelins, par exemple, si l’utilisateur les créant appuie sur le bouton Annuler pendant le processus. Dans ce cas, leurs pièces jointes sont créées et jamais supprimées. Pire, ils ne sont pas répertoriés sur la page d’inventaire des packs de données dans Omnistudio, ce qui rend plus difficile pour les administrateurs de les détecter.

Lorsqu’ils sont intégrés dans un site Web externe, FlexCard ou Omniscript Components ont besoin d’un jeton d’accès pour accéder à Salesforce. Ces jetons doivent être créés à l’aide d’une application Omniout. Cependant, l’utilisateur final d’un site Web peut inspecter les demandes d’API localement dans leurs navigateurs et extraire ce jeton, qui peut ensuite être utilisé à mauvais escient. Costello recommande que les entreprises utilisent un proxy pour la communication entre les composants omnistudio externes et Salesforce.

Un proxy, cependant, n’aidera pas lorsque le jeton lui-même est intégré dans le code OMNIOut qui a été compromis ou stocké dans des systèmes de contrôle de version publique comme GitHub. De plus, un proxy pourrait introduire des risques s’il est mal configuré pour transmettre les demandes sans validation, car les utilisateurs pourraient tenter de falsifier les paramètres et les valeurs.

« Étant donné que Omniout repose généralement sur des API Salesforce authentifiées, cette exigence de compte est satisfaite en fournissant au composant Omniout un jeton d’accès à application connecté qui sera utilisé pour faire des demandes au nom de tous les utilisateurs externes », a noté le chercheur. «Bien qu’il ne soit pas explicitement énoncé dans la documentation Salesforce qui détaille le processus de création de l’application connectée, il est impératif que les organisations ne génèrent pas de jeton d’accès pour Omniout qui est lié à un compte privilégié tel que l’administrateur système.»

Enfin, les OmniScripts, qui lient plusieurs opérations back-end via IPROCS, les mappeurs de données et les flexcards, ont une fonctionnalité appelée session enregistrée qui permet aux utilisateurs de sauvegarder leur progression et de revenir au script plus tard. Lorsque de telles sessions sont générées, un enregistrement est créé dans la session enregistrée Omniscript SOBject avec toutes les données entrées ou renvoyées par le script jusqu’à ce qu’il soit enregistré. Par défaut, il n’y a pas de temps d’expiration pour ces sessions enregistrées.

« Bien que les utilisateurs du site invité et / ou de la communauté n’aient pas la possibilité de sauvegarder leurs propres sessions, cela ne les empêche pas de lire les données d’autres séances d’utilisateur s’ils sont accordés les autorisations pour le faire, faisant de ce vecteur d’attaque un risque qui pourrait être profité par les identités internes et externes », a révélé le chercheur.

Atténuation

Pour les configurations non sécurisées que Salesforce n’a pas déjà corrigées, Appomni fournit des recommandations d’atténuation dans son article, y compris une liste d’objets qui devraient avoir leur objet, leur champ et les configurations de règles de partage audidité régulièrement. Réduire le niveau d’accès pour Omnistudio Sobjects et leurs dossiers uniquement ce qui est nécessaire est la première ligne de défense, a indiqué la société.