La sécurité est au cœur des préoccupations des éditeurs d’application SaaS. En effet, elle est indispensable pour que les utilisateurs accordent leur confiance à la solution et pour garantir que les données seront protégées.
Sécurité de l’authentification, cloisonnement des données, chiffrement des données, mais aussi sécurité du parcours utilisateur, continuité de service et intégrations tierces… Les problématiques sécurité des applications SaaS sont multiples. Un pentest permet d’évaluer la robustesse d’une plateforme SaaS afin de mettre à l’épreuve et éventuellement de renforcer son niveau de sécurité. Voici une liste des aspects qui méritent une attention particulière lors d’un pentest.
SOMMAIRE :
- Tester la sécurité des données
- Tester la sécurité du parcours utilisateur sur les applications SaaS
- Garantir la continuité de service des applications SaaS
- Valider la sécurité des intégrations tierces
- Réaliser un pentest d’application SaaS
Les enjeux prioritaires lors d’un pentest d’application SaaS
Les applications SaaS représentent un très large éventail de solutions : ressources humaines, ventes, comptabilité, marketing… mais elles partagent les mêmes enjeux principaux de sécurité. Voici les priorités lors d’un test d’intrusion, d’après notre expérience.
Tester la sécurité des données d’une application SaaS
Sécurité de l’authentification
L’authentification des utilisateurs constitue une étape particulièrement sensible. Elle détermine si l’utilisateur a un accès légitime et accorde les autorisations correspondantes (rôle et niveau d’accès).
Interface visible depuis l’extérieur de l’application, elle subit de nombreuses attaques et doit être résistante. La solidité et l’étanchéité de l’interface de connexion sont un enjeu pour tout logiciel SaaS.
L’authentification peut soit être gérée par la plateforme SaaS, soit par un SSO (Single Sign On). Dans les deux cas, l’implémentation doit être rigoureuse pour qu’il soit impossible de la contourner. Un pentest vérifiera par exemple les contrôles d’accès, les politiques d’identifiants, le stockage des accès, les clés d’accès, etc.
Cloisonnement vertical des données
Les applications SaaS fonctionnent généralement en proposant différents rôles pour les utilisateurs, par exemple : utilisateur, manager, administrateur.
La mise en place de différents niveaux de privilèges doit être basée sur les fonctionnalités pour renforcer la séparation des privilèges entre différents utilisateurs, groupes ou bases clients d’une organisation. Il est important de veiller au principe du moindre privilège, c’est-à-dire donner à chaque rôle uniquement les droits dont il a besoin. C’est une première précaution pour limiter les possibilités d’élévation de droits.
Nous rencontrons fréquemment des problèmes de droits entre les utilisateurs lors des pentests. Il s’agit de vulnérabilités qui permettent à un utilisateur standard de s’accorder des fonctions supplémentaires, auxquelles il ne devrait pas avoir accès (par exemple, un compte utilisateur standard obtient les droits d’un manager pour valider une note de frais dans une application RH).
Cloisonnement horizontal des données
La spécificité d’une plateforme SaaS, c’est qu’elle héberge tous ses clients sur une même infrastructure, des mêmes serveurs, une même base de données. La séparation des données selon les comptes se fait au niveau de la couche applicative, par des contrôles d’authentification et de droits.
L’hébergement multi-tenants est l’offre la plus courante, car elle permet de réduire les coûts du service proposé en mutualisant les équipements hardware, les instances…
La confidentialité des données exige que les comptes des clients soient étanches les uns des autres. Des problèmes de configuration et des failles de droits peuvent créer des possibilités d’accéder à un autre compte que celui normalement prévu. Un test d’intrusion pourra vérifier que le cloisonnement des données est bien effectué.
Pour leurs clients qui ont de fortes contraintes sécurité, certains éditeurs proposent une instance dédiée, afin de réduire les risques d’accès non autorisés à des données.
Chiffrement des données
Le chiffrement des données est une mesure indispensable pour garantir la confidentialité des données d’un logiciel SaaS. Elle doit être mise en place pour le stockage des données, mais également pour les données en transit. Ainsi, si jamais une fuite de données se produit ou bien si des attaquants interceptent des informations, elles seront illisibles et inutilisables.
Le chiffrement au repos signifie que la base de données stocke les éléments chiffrés. Le chiffrement en transit implique que lors d’imports, d’exports ou de transferts, les données restent chiffrées de bout en bout. Le protocole pour accéder à la base de données doit permettre le chiffrement.
Les clés de chiffrement sont une information très sensible. Il est recommandé de les stocker dans un endroit distinct des données qu’elles chiffrent. Fréquemment, le client peut gérer lui-même les clés de chiffrement (service et stockage).
Le chiffrement des données peut être un critère déterminant lors d’un choix d’une plateforme SaaS, c’est pourquoi c’est un sujet important à tester lors d’un audit de sécurité. Un test d’intrusion contrôlera par exemple si le chiffrement est adapté et bien configuré, si les clés de chiffrements sont stockées et appelées de manière sécurisée, etc.
Tester la sécurité du parcours utilisateur sur les applications SaaS
Les plateformes SaaS sont souvent des logiciels métiers avec des processus complexes. La nature des activités nécessite de prendre en compte les risques de fraude et de manipulation des étapes.
L’enjeu est de vérifier qu’un attaquant ne puisse pas contourner le parcours client et les workflows prévus, que ce soit par des failles techniques ou des failles logiques.
Les failles techniques sont des erreurs dans le code, d’implémentation ou de configuration, tandis que les failles logiques ne sont pas des erreurs à proprement parler, mais des failles liées au fonctionnement de la plateforme. Un comportement non prévu a pu être obtenu.
Les failles logiques sont plus difficiles à détecter que les failles techniques, car les pentesters doivent comprendre le fonctionnement complet de l’application avant de pouvoir essayer de le contourner.
Les vulnérabilités liées au parcours utilisateur se trouvent fréquemment dans les nombreuses requêtes, avec de multiples paramètres que les applications SaaS envoient. Lors d’un pentest, il s’agit d’analyser les requêtes, la validation des fichiers, les contrôles des différentes étapes pour s’assurer qu’il n’y a pas de failles.
Garantir la continuité de service des applications SaaS
De nombreux éditeurs de plateforme SaaS sont particulièrement attentifs à se protéger des dénis de service, car le cœur de leur business model est d’être un service tout le temps disponible. L’éditeur ne peut pas prendre le risque d’avoir un service dégradé ou pire, totalement inaccessible.
C’est pourquoi les éditeurs d’application SaaS cherchent à renforcer leur infrastructure face à ces offensives. Lors d’un test d’intrusion, nous vérifions la résistance du système face à des attaques par saturations de sessions, par inondations de paquets (packet flooding), face à des dénis applicatifs (liés à des fonctionnalités du logiciel SaaS testé)…
Les vulnérabilités détectées se trouvent au niveau configuration ou applicatif, pour lesquelles des remédiations existent (et qui ne dépendent pas de votre hébergeur).
Valider la sécurité des intégrations tierces
Les applications SaaS s’imbriquent de plus en plus les unes aux autres, car elles ont régulièrement besoin des données supplémentaires pour réaliser leurs tâches. Les intégrations tierces se reposent de manière croissante sur des APIs. Mais cette intégration peut être source de failles de sécurité.
En effet, les intégrations créent de nouveaux points d’entrées ou de sortie de l’application SaaS, qui potentiellement sont moins inclus dans les tests de sécurité. Il faut s’assurer que les mêmes contrôles sont mis en place à ces endroits. Les échanges de données doivent être sécurisés contre les interceptions et modifications, et plus généralement contre les tentatives d’attaques par ces canaux-là.
Réaliser un pentest d’application SaaS
Le test d’intrusion d’une plateforme SaaS soumet l’application à des attaques réalistes, avec les mêmes outils et techniques qu’un attaquant malveillant pourrait utiliser. Cela donne de la visibilité sur les points déjà solides et sur ceux à renforcer en priorité.
Tester les configurations serveurs et l’hébergement cloud
L’hébergement représente un facteur crucial dans la sécurité d’une plateforme SaaS. Lors d’un pentest SaaS, nous testons en particulier la configuration de l’hébergement, les règles de gestions des identités et des sessions, les restrictions de trafic, les services ouverts…
Les instances peuvent être testées en boite noire, afin de simuler un attaquant externe, ou en boite grise, en ayant des droits limités sur l’application.
Vous pouvez aussi conduire un audit en boite blanche. Cet audit technique permet une revue en profondeur des configurations serveurs cloud, afin de détecter des erreurs et de recommander les best practices sécurité des différents environnements. Nos consultants disposent pour cela de connaissances spécifiques sur les environnements cloud (par exemple : AWS).
L’audit en boite blanche permet de s’assurer que toute l’application SaaS est testée en détail. Cela nécessite pour l’éditeur de fournir aux pentesters un accès admin à l’infrastructure pour les tests.
Tester la couche applicative des plateformes SaaS
Comme toutes les applications web, les applications SaaS délivrent un service via le web. Lors d’un test d’intrusion, un volume important de tests se concentrent sur la couche applicative, source de vulnérabilités techniques et logiques.
Un pentest applicatif peut être mené en boite noire, en boite grise ou en boite blanche.
En boite noire, les tests ciblent la surface d’attaque accessible depuis l’extérieur, afin de tester l’ensemble des risques sur le périmètre accessible à un attaquant externe. Vous ne fournissez aucune information ou compte en amont des tests.
En boite grise, nous menons les tests à partir d’un compte utilisateur standard, fourni généralement au début de l’audit. L’intérêt est de tester notamment les élévations de droits et l’étanchéité des comptes.
En boite blanche, l’analyse est poussée encore plus loin en donnant accès au code source du logiciel SaaS.
Inclure des tests d’ingénierie sociale pendant un pentest d’application SaaS
Pour aller plus loin, un pentest d’application SaaS peut aussi inclure des tests sur les facteurs humains. Les attaques d’ingénierie sociale constituent un vecteur d’attaques fréquent, car elles sont très efficaces lorsque les équipes ne sont pas sensibilisées à ces risques. Pour un attaquant, l’ingénierie sociale permet de contourner les protections techniques lorsque celles-ci sont solides.
Les attaques par ingénierie sociale s’appuient sur les ressorts du comportement humain pour pousser à l’erreur les utilisateurs : cliquer sur un mail de phishing, dévoiler un mot de passe, exécuter une payload, etc.
Inclure des tests d’ingénierie sociale dans un pentest SaaS sensibilise vos équipes internes. Il s’agit d’identifier les possibilités de compromettre l’application ou les données des clients, via des attaques réalistes ciblant les équipes de l’éditeur de solution. En revanche, il n’est généralement pas possible de tester les clients de l’éditeur de plateforme, pour des questions à la fois de coût et de responsabilité. Mais il est utile pour un éditeur d’informer ses clients au sujet de ce type de risques.
