Du code Apex non sécurisé dans les déploiements Salesforce

Des experts de Varonis alertent sur la présence d’instances de code Apex non sécurisé dans les déploiements Salesforce de nombreuses entreprises, laissant craindre de sérieuses vulnérabilités qui mettent en danger leurs données et les workflows. Ces derniers disent avoir trouvé des failles de gravité élevée et critique dans le code Apex utilisé par plusieurs entreprises du Fortune 500 et des agences gouvernementales.

« Si elles sont exploitées, ces vulnérabilités peuvent entraîner des fuites et des corruptions de données et nuire aux fonctions métiers de Salesforce », ont expliqué les chercheurs dans un rapport. « C'est la raison pour laquelle 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 ».

Des classes Apex insuffisamment restreintes

Apex est un langage de programmation orienté objet dont la syntaxe est similaire à Java et que les développeurs peuvent utiliser pour exécuter des instructions de flux et de contrôle sur les serveurs Salesforce ainsi que des appels via l'API Salesforce. Apex propose aux utilisateurs de personnaliser leurs instances Salesforce en ajoutant une logique métier supplémentaire aux événements du système, notamment les clics sur les boutons, les mises à jour d'enregistrements connexes et les pages Visualforce. « Une classe Apex est un template ou un blueprint utilisé pour créer des objets Apex », ont encore expliqué les spécialistes. « Les classes comprennent d'autres classes, des méthodes définies par l'utilisateur, des variables, des exceptions de types et un code d'initialisation statique ». Elles constituent donc un outil puissant pour les développeurs, mais il est également très important d'examiner attentivement leurs capacités et de restreindre les personnes qui peuvent y accéder.

Le code Apex peut fonctionner en deux modes « sans partage » et « avec partage ». Dans le premier, le code Apex ignore les autorisations de l'utilisateur et peut accéder à n'importe quel enregistrement et apporter des modifications, alors que dans le second, le code respecte les autorisations de l'utilisateur au niveau de l'enregistrement mais ignore celles au niveau de l'objet et du champ. Les classes Apex configurées pour fonctionner en mode « sans partage » sont parfois nécessaires pour mettre en œuvre des fonctionnalités importantes, mais elles peuvent présenter un risque sérieux, en particulier quand elles sont mises à la disposition d'invités ou d'utilisateurs externes. Parmi les problèmes les plus courants pouvant découler des classes Apex, on peut citer les références directes d'objets non sécurisées (Insecure Direct Object References, IDOR), où un attaquant peut lire, manipuler ou supprimer des tables complètes de données auxquelles il ne devrait pas avoir accès, ou l'injection SOQL ; et l'injection SOSL, où le code présente des failles qui permettent aux attaquants de manipuler les requêtes effectuées par la classe pour exfiltrer des données ou modifier le flux de processus prévu.

Vérifier l’appel des classes Apex

Les experts recommandent aux entreprises de vérifier qui peut appeler les différentes classes Apex utilisées dans leurs instances et leurs capacités, en particulier les classes qui fonctionnent en mode « sans partage ». Cette opération peut être réalisée manuellement en passant en revue chaque classe, mais ce processus prend du temps. « Pour déterminer qui peut appeler une classe Apex, il faut vérifier à la fois les profils et les ensembles de permissions (depuis Winter, si l’on clique sur « Sécurité » en examinant la classe Apex elle-même, on ne peut voir que les profils, ce qui n'est pas suffisant pour déterminer qui peut appeler une classe Apex) », mettent en garde les chercheurs. La bonne façon de procéder est d'aller d'abord dans la section « Utilisateur », puis dans « Profils », et de cocher la case « Accès activé à la classe Apex » (Enabled Apex Class Access) dans chaque profil. Ensuite, pour chaque entrée de l'option « Accès activé à la classe Apex », l'administrateur doit faire défiler la section Apps et cliquer sur l'option « Accès à la classe Apex » (Apex Class Access) pour voir les droits. En outre, pour vérifier si une classe Apex est configurée pour fonctionner « sans partage », son code source peut être examiné, car la chaîne « sans partage » se trouve dans l'une des premières lignes de la déclaration de la classe.

Le rapport Varonis comprend également des bonnes pratiques sur la manière de sécuriser le code Apex pour éviter les entrées non sécurisées qui peuvent conduire à une injection SOQL ou SOSL. Selon le modèle de responsabilité partagée, ce sont les clients de Salesforce et non Salesforce qui sont responsables de la sécurité de leur code Apex. « Une stratégie de sécurité complète devrait vérifier que les classes Apex ont été examinées par des spécialistes de la sécurité, et pas seulement par les développeurs et les administrateurs de Salesforce », ont déclaré les chercheurs. « C'est généralement le cas pour le code qui fait partie d'un paquet AppExchange, mais ce n'est pas toujours le cas pour les autres codes qui ne font pas partie d'AppExchange. Cela s'applique particulièrement au code interne, qui est souvent négligé. »