La sécurité des applications web est un enjeu majeur pour les entreprises. Plateformes SaaS, outils internes ou sites e-commerce, tous ces systèmes doivent être sécurisés pour contrer des attaques de plus en plus nombreuses ciblant toutes leurs fonctionnalités et composantes : serveurs, APIs, authentification, session, contrôle d’accès, composants tiers, etc.
Au-delà de l’aspect protection contre des attaques, la sécurité est également devenue un point clé et un atout différenciant dans les phases d’avant-vente, notamment en B2B.
Sécuriser vos applications web est donc vital et cela passe nécessairement par l’implémentation des meilleures pratiques en termes de développement et tests sécurité. Dans cet article, nous nous focaliserons sur les bonnes pratiques permettant de sécuriser les systèmes d’authentification, de gestion de sessions et de contrôle d’accès de vos applications web.
Quelles sont les bonnes pratiques pour sécuriser les systèmes d’authentification, de gestion des sessions et de contrôle d’accès de vos applications web ?
Authentification et gestion des sessions
Les systèmes d’authentification et de gestion des sessions sont des fonctionnalités critiques des applications web. L’authentification permet de s’assurer que seuls des utilisateurs légitimes peuvent accéder à l’application tandis que le mécanisme des sessions assure le suivi des diverses actions réalisées par les utilisateurs sur l’application.
Souvent ciblées lors d’attaques, les vulnérabilités exploitées sur ces mécanismes permettent aux attaquants d’usurper ou de détourner des comptes ou des sessions utilisateurs. Il est donc nécessaire de concevoir des systèmes sécurisés pour contrer ces attaques et garantir l’intégrité de vos données.
Ci-dessous les bonnes pratiques pour sécuriser les systèmes d’authentification et de gestion des sessions :
Pour sécuriser l’authentification
- Ne pas coder en dur les identifiants et/ou mots de passe.
- Faire en sorte que chaque compte utilisateur soit nominatif et utilisé uniquement par l’utilisateur auquel il est associé. Cela facilitera l’identification des incidents de sécurité ou des failles potentielles.
- Gérer correctement les messages d’erreurs d’authentification.
Les messages d’échec de connexion ne doivent pas indiquer l’origine de l’erreur (identifiant inconnu ou mot de passe invalide par exemple), car cela fournit des informations précieuses à un attaquant.
En effet, lors d’une attaque par force brute par exemple, un message d’échec de connexion tel que « mot de passe invalide » permet à un attaquant de se concentrer sur l’identifiant renseigné, ce qui lui fait gagner beaucoup de temps.
De plus, cela facilite l’énumération d’utilisateurs et donc des fuites de données lorsque l’identifiant est l’adresse email de l’utilisateur (ce qui est par ailleurs assez fréquent). Ces données peuvent être utilisées dans des attaques d’ingénierie sociale et notamment de spear phishing.
- Mettre en œuvre une politique de mot de passe efficace.
La sécurité de l’authentification passe naturellement par la mise en place d’une politique de mot de passe efficace. En premier lieu, la complexité du mot passe qui doit être imposée lors de la création d’un compte : il doit être suffisamment long (15 à 20 caractères).
Par ailleurs, les identifiants contenus dans les mots de passe, le nom de l’entreprise ou de l’application suivi de l’année et d’un point d’exclamation sont des pratiques répandues et connues des attaquants, qui réalisent souvent des attaques par password spraying. Il est donc recommandé de forcer la création de mots de passe ne contenant pas à minima l’identifiant et de sensibiliser les utilisateurs aux risques liés à l’utilisation de mots de passe trop prévisibles.
Autre point : les politiques d’expiration de mots de passe visant à encourager les changements fréquents de mots de passe pour prévenir des éventuelles fuites de données. À première vue, cela apparait comme une bonne mesure de sécurité. Cependant l’analyse des comportements des utilisateurs montre une tout autre réalité. En effet, la plupart du temps, les utilisateurs se contentent de créer un autre mot de passe non sécurisé car facile à deviner et à craquer par des attaquants. Il est donc recommandé de bannir ces politiques d’expiration de mots de passe et de tout simplement inciter les utilisateurs à choisir un mot de passe suffisamment long et complexe.
- Vérifier que tous les contrôles d’authentification sont réalisés côté serveur et non côté client.
- Demander le mot de passe utilisateur avant toute opération sensible (modification d’informations sensibles : mot de passe, comptes de messagerie, informations de paiement, etc.).
- Implémenter un système de réinitialisation de mots de passe sécurisé.
La fonction « mot de passe oublié » et les autres chemins de récupération ne doivent pas révèler le mot de passe actuel ; et le nouveau mot de passe ne doit jamais être envoyé en clair à l’utilisateur.
Un token unique, composé d’une chaine de caractères aléatoire, doit être généré à chaque demande de réinitialisation puis invalidé une fois la réinitialisation effectuée.
- Implémenter des mesures techniques anti « brute force ». Par exemple :
- Limiter le nombre de connexions non valides et augmenter le délai après et entre chaque tentative de login.
- Mettre en place un blocage temporaire d’IP et/ou l’affichage d’un CAPTCHA après plusieurs essais de connexion infructueux.
- Implémenter un système d’authentification à plusieurs facteurs, de préférence via des applications d’authentification telles que Google Authenticator, afin de s’assurer que le processus d’authentification est réalisé par une personne et non par un bot.
- Stocker les mots de passe des utilisateurs avec une fonction de hachage robuste, itérative et salée.
Les mots de passe utilisateurs ne doivent jamais être stockés en clair. Ils doivent être stockés en utilisant des techniques de hachage sécurisées par dérivation de clé telles que l’algorithme bcrypt.
Pour plus d’informations, nous vous renvoyons vers notre article : comment stocker les mots de passe de manière sécurisée dans une base de données ?
Pour sécuriser la gestion des sessions
- S’assurer que les identifiants de session sont générés automatiquement et composés d’une chaine aléatoire de caractères, unique et suffisamment longue pour éviter des détournements de session par prédiction.
- Générer un nouveau jeton de session après authentification d’un utilisateur pour éviter les attaques par fixation de session.
- Implémenter un délai d’expiration des sessions et forcer une nouvelle authentification lorsque les utilisateurs sont inactifs pour atténuer le risque qu’un attaquant utilise une session détournée pendant une longue durée.
- Détruire une session et les données associées sur le serveur lorsqu’un utilisateur se déconnecte de l’application.
- Ne pas exposer les identifiants de session dans les URLs.
- Utiliser des attributs sécurisés pour les cookies de session, notamment HTTPOnly, secure et samesite.
HTTPOnly permet d’éviter que l’identifiant de session soit accessible aux scripts Javascript, ce qui permet de contrer certaines méthodes de vol de session.
L’attribut « Secure » quant à lui, informe les navigateurs que l’identifiant de session ne doit transiter que via des canaux HTTPS, ce qui permet de contrer certaines attaques basées sur l’écoute du réseau.
Enfin, l’attribut « samesite » qui permet de se protéger contre des attaques de type CSRF. Pour plus d’informations, vous pouvez consulter notre article : se protéger des attaques CSRF avec l’instruction SameSite sur les cookies
Sécurité du contrôle d’accès des applications web
Le contrôle d’accès est le processus consistant à accorder ou refuser l’accès à une ressource ou une fonctionnalité spécifique, en fonction des droits initialement attribués.
Souvent exploitées par les attaquants, les vulnérabilités liées au manque de contrôle d’accès permettent aux attaquants d’accéder aux informations d’autres utilisateurs, d’obtenir des accès utilisateurs à privilèges élevés voire des accès administrateurs.
Ci-dessous les bonnes pratiques pour sécuriser le contrôle d’accès sur vos applications web :
- S’assurer que toutes les pages de l’application, qui ne doivent pas être publiques, ont un contrôle d’authentification.
- Attribuer les droits d’accès en appliquant le principe du moindre privilège.
- Contrôler les droits de l’utilisateur quand une référence directe à un objet (ID) est effectuée avant de lui retourner les ressources concernées.
- Ne pas laisser les utilisateurs avoir un accès direct à l’arborescence des fichiers sur le serveur.
- Révoquer les accès des ex-utilisateurs de l’application.
Réaliser un test d’intrusion pour tester la sécurité de vos applications web
Les applications web sont des cibles particulièrement attrayantes pour les attaquants, en raison de l’étendue de leur surface d’attaque et de vulnérabilités trop souvent ignorées lors des phases de développement ou de déploiement de nouvelles fonctionnalités.
Implémenter les bonnes pratiques de développement revêt donc une importance capitale, car cela permet d’éviter des erreurs de programmation et de configuration, donc de multiplier des vulnérabilités qui pourraient être facilement exploités par des attaquants. Cependant, il faut s’assurer de la solidité de votre application web face à des attaques réelles. C’est ce à quoi répondent les tests d’intrusion (ou pentest).
Un test d’intrusion est une simulation d’attaque qui vise à confirmer ou à infirmer l’efficacité des contrôles de sécurité dans un système spécifique en mettant en évidence les risques posés par des vulnérabilités exploitables. Il s’articule autour d’un processus de tests manuels, qui vise à aller beaucoup plus loin que des audits de sécurité via des scanners de vulnérabilités.
Sur une application web, il s’agira notamment de rechercher des vulnérabilités à la fois côté serveur et sur la couche applicative, avec 3 approches possibles : des tests en boite noire, en boite grise ou en boite blanche.
En boite noire, les pentesters ne disposeront d’aucune information ou accès spécifique sur l’application, tandis qu’en boite grise, les tests seront réalisés avec des accès utilisateur standards. Dans ce cas de figure, il s’agira notamment de réaliser des tests de droits pour vérifier le bon cloisonnement des données et ainsi s’assurer qu’un utilisateur A ne peut pas accéder aux données d’un utilisateur B (cloisonnement horizontal des données) ou d’un administrateur (cloisonnement vertical des données).
Pour une analyse plus approfondie, des tests en boite blanche peuvent être envisagés. Dans ce cas de figure, il s’agira de fournir aux pentesters le code source de l’application.
Quels que soient l’approche retenue ou le périmètre des tests, un rapport complet est réalisé suite à un test d’intrusion. Il inclut la méthodologie suivie, les vulnérabilités identifiées, le niveau de criticité, l’exploitation possible ainsi que des recommandations de correction. Le test d’intrusion pourra être complété par une phase de validation des corrections permettant de vérifier leur bonne implémentation et l’absence d’effets de bord.
Un test d’intrusion reste la solution par excellence pour tester la résistance de votre application web. Il permet non seulement d’identifier les points faibles de sécurité, mais aussi de sensibiliser les développeurs et utilisateurs sur les bonnes pratiques à instaurer en matière de cybersécurité.
Contactez-nous pour toute question relative à un projet de tests d’intrusion sur votre application web. Nous échangerons sur vos besoins et vous proposerons une intervention adaptée à vos enjeux sécurité et vos contraintes.