Les vulnérabilités et erreurs de configuration dans le langage Apex, utilisé pour personnaliser les instances Salesforce, mettent en lumière des risques sécuritaires significatifs, touchant des organisations de toutes tailles.
Des vulnérabilités majeures et graves ainsi que des erreurs de configuration dans Apex, le langage de programmation de type Java qui est largement utilisé pour personnaliser les instances Salesforce ont récemment été notifiées.
Ces erreurs de configuration ont été notées au sein de plusieurs entreprises du classement Fortune 500 ainsi que dans des agences gouvernementales.
D’après nos experts, ces risques ne sont pas l’apanage des grandes entreprises. Dans la mesure où le code Apex est intégré dans de nombreuses applications « prêtes à l’emploi », les entreprises de toutes tailles et de tous secteurs qui sont menacées.
Si elles venaient à être exploitées, ces vulnérabilités pourraient causer des pertes et la corruption des données, ainsi que des dysfonctionnements dans les opérations commerciales de Salesforce. C’est pourquoi il est essentiel de garder une trace des classes Apex et de leurs propriétés, de savoir qui peut les exécuter et comment elles sont utilisées.
Dans le cadre du modèle de responsabilité partagée, ce sont les clients de Salesforce, et non Salesforce à qui incombe la responsabilité de la sécurité du code Apex qu’ils mettent en œuvre. Dans la mesure où ce sont eux qui exploitent Apex, c’est à eux qu’il revient de corriger les classes, les déclencheurs ou le code Apex qui exposent les vulnérabilités.
Le langage de programmation Apex permet aux utilisateurs d’écrire leur propre code et leur propre logique. C’est l’un des outils les plus couramment utilisés pour personnaliser les instances Salesforce.
Les développeurs utilisent ce langage, qui est à la fois fortement typé et orienté objet, pour exécuter des instructions de contrôle des flux et des transactions sur le serveur de la plateforme Salesforce Lightning, en complément d’appels d’API de la plateforme Lightning.
Apex offre aux développeurs la possibilité d’ajouter une logique métier à la plupart des événements système, notamment aux clics de boutons, aux mises à jour d’enregistrements associés et aux pages Visualforce. Sa syntaxe, similaire à celle de Java, agit comme des procédures stockées dans une base de données. Le code Apex peut être initialisé par des demandes émanant de services Web et de déclencheurs d’objets.
Apex alimente ainsi de nombreuses fonctionnalités de Salesforce, conférant à cette plateforme une puissance et une personnalisation remarquables. Cependant, cette intégration exhaustive peut également engendrer des vulnérabilités.
Les vulnérabilités d’Apex
Le code Apex peut être exécuté dans deux modes différents :
« Without sharing » – ce mode signifie que le code Apex ignore les autorisations de l’utilisateur. Le code peut accéder à n’importe quel enregistrement et effectuer des modifications, et « With sharing » – ce mode signifie que le code Apex respecte les autorisations de l’utilisateur au niveau de l’enregistrement, mais ignore les autorisations au niveau de l’objet et du champ.
Les classes Apex qui s’exécutent « without sharing », c’est-à-dire sans tenir compte des autorisations de l’utilisateur, sont un outil puissant et précieux, souvent nécessaire au bon fonctionnement de l’application. Cependant, qui dit grand pouvoir dit aussi grandes responsabilités. Ce mode augmente les risques et doit être utilisé avec précaution, en particulier lorsqu’il est attribué à des utilisateurs invités ou externes.
Utilisation abusive des classes Apex vulnérables
Pour illustrer ces vulnérabilités en toute sécurité, VTL a créé un environnement Salesforce basé sur les vulnérabilités réelles du code Apex qu’ils ont rencontré.
La première étape consiste à effectuer une reconnaissance. Dans cet exemple, nous extrairons des données du champ d’un utilisateur que nous intitulerons « VerySecretFlag », mais il pourrait s’agir de numéros de téléphone, de numéros de sécurité sociale ou d’autres données sensibles.
Chose intéressante, il est impossible de récupérer la valeur renvoyée autrement que par Apex, même avec Aura. En d’autres termes, l’utilisateur invité ne peut pas accéder à cet enregistrement. On peut donc en déduire que la classe Apex fonctionne « without sharing ». Pour récupérer la valeur du « VerySecretFlag », un attaquant a besoin d’une classe configurée pour s’exécuter « without sharing ».
Limiter la casse
Apex est un élément essentiel de Salesforce. Pour améliorer la sécurité de votre instance Salesforce, il convient de vérifier les différentes classes Apex possédées et de mettre particulièrement l’accent sur celles qui s’exécutent « without sharing ».
Même si cette opération puisse être effectuée manuellement, elle requiert un investissement considérable en termes de temps et d’efforts.
Une stratégie de sécurité complète doit garantir que les classes Apex ont été examinées par des professionnels de la sécurité et pas seulement par des développeurs ou des administrateurs Salesforce. C’est généralement vrai pour les codes intégrés dans un package AppExchange, mais ce n’est pas toujours le cas pour d’autres codes qui ne font pas partie d’AppExchange. Il en va de même pour le code interne, qui est souvent négligé.
Toute classe Apex vulnérable peut causer des pertes et des corruptions de données. Sachant que les clients de Salesforce sont en fin de compte les seuls responsables de la sécurité du code Apex qu’ils mettent en œuvre, les entreprises doivent gérer en toute sécurité les classes Apex et leurs propriétés, les personnes autorisées à les exécuter et la manière dont elles sont utilisées.
____________________________
Par Jérôme Soyer, Vice President Avant-Vente pour l’Europe Continentale chez Varonis
puis