Sécurisation des applications grâce à l’authentification et aux contrôles d’accès
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Décrire l’importance d’exiger une authentification et de contrôler les accès
- Expliquer les méthodes d’attaque qui exploitent les failles dans les procédures d’authentification
- Répertorier les méthodes d’attaque qui exploitent les défaillances des contrôles d’accès
Authentification et accès aux applications
Réfléchissez à la sécurité dans un aéroport. Avant l’embarquement, les passagers doivent présenter une preuve de leur identité à l’agent chargé du contrôle des billets, qui vérifie que cette pièce d’identité correspond bien aux renseignements indiqués sur la liste des passagers et que son détenteur ne figure pas au sein d’une base de données de personnes malveillantes. Ces étapes d’authentification physique ressemblent beaucoup aux étapes d’authentification logique que les utilisateurs de ressources technologiques (y compris les applications) doivent effectuer avant de pouvoir accéder à celles-ci.
Les ingénieurs en sécurité des applications limitent l’accès aux données aux utilisateurs identifiés, authentifiés et autorisés. L’authentification vérifie l’identité d’une personne par le biais d’identifiants, généralement un nom d’utilisateur et un mot de passe, qui sont employés pour se connecter à une application. Cela permet à l’application d’accorder aux utilisateurs les privilèges adéquats, qui restreignent leur accès à certains éléments et leur permettent d’accéder à d’autres. Ce concept d’octroi et de restriction de l’accès aux ressources est appelé autorisation. L’ensemble du processus d’identification et d’authentification des utilisateurs, ainsi que d’octroi d’autorisations à ceux-ci, est appelé contrôle d’accès.
Les ingénieurs en sécurité des applications ont un rôle essentiel à jouer dans la gestion des autorisations d’application, des connexions et des autorisations des utilisateurs. Exercer une telle gestion permet de se protéger contre les attaquants qui compromettent les mots de passe, les clés ou les jetons. Dans cette optique, les ingénieurs d’application contrôlent, gèrent et auditent l’accès aux applications, en particulier les accès privilégiés (accès administrateur).
Les ingénieurs exécutent des applications en utilisant le moins de privilèges possible (il s’agit du concept du « moindre privilège »). Ils testent également l’application afin d’y détecter d’éventuels problèmes de contrôle d’accès verticaux et horizontaux. Un problème horizontal se caractérise par le fait qu’un utilisateur puisse consulter/modifier les informations d’un autre utilisateur. Un problème vertical se caractérise par le fait qu’un utilisateur puisse obtenir un accès administratif de manière inappropriée.
Par exemple, les ingénieurs en sécurité des applications mettent en place des protections empêchant l’utilisation de références d’objet directes non sécurisées, qui permettent aux attaquants de contourner le processus d’autorisation et d’accéder directement aux ressources du système. Un tel cas de figure se produit lorsqu’une application traite une saisie effectuée par un utilisateur et l’utilise pour récupérer un objet (tel qu’un enregistrement ou un fichier de base de données) sans effectuer de vérifications d’autorisation suffisantes.
Un jeton est généralement utilisé de la façon suivante : au lieu d’avoir à s’authentifier pour accéder à chaque ressource, l’utilisateur s’authentifie une fois de la manière requise (au sein d’une session d’une durée limitée), obtient en retour du serveur un jeton temporaire, et utilise les données d’identité que contient ce jeton lorsqu’il doit s’authentifier à nouveau pendant la session.
Protection contre les procédures d’authentification défaillantes
L’authentification défaillante constitue l’un des risques contre lesquels les ingénieurs en sécurité des applications protègent leur entreprise. Ce risque se manifeste lorsqu’un attaquant obtient un accès non autorisé aux comptes et compromet un système. L’impact de ce risque peut être grave, car dans un tel cas de figure, un attaquant pourrait blanchir de l’argent, ou encore voler les prestations de sécurité sociale d’une personne, voire son identité. Le risque que des attaquants exploitent une authentification défaillante est élevé.
Les attaquants peuvent facilement accéder à des noms d’utilisateur et des mots de passe valides en devinant ces informations grâce à la présence d’une personne sur les réseaux sociaux, ou en employant des identifiants valides achetés sur le Dark Web (cette technique est connue sous le nom de « bourrage d’identifiants »). Les attaquants testent si les applications et les logiciels associés utilisent des comptes d’administrateur par défaut. Si toutes les autres méthodes échouent, l’attaquant a recours à une attaque par force brute pour deviner le mot de passe de l’utilisateur ou emploie un programme automatisé qui saisit systématiquement chaque mot d’un dictionnaire en tant que mot de passe (cette méthode est appelée « attaque par dictionnaire ») pour obtenir un accès de manière illicite.
On parle de bourrage d’identifiants lorsqu’un attaquant récupère les noms d’utilisateur et les mots de passe compromis lors d’une violation majeure des systèmes d’une autre entreprise et utilise ces identifiants pour se connecter à d’autres services numériques. Étant donné que de nombreuses personnes utilisent les mêmes noms d’utilisateur et mots de passe sur plusieurs sites, cela permet aux attaquants d’accéder à d’autres comptes que ceux initialement compromis.
Tout cela semble plutôt effrayant. Alors, comment les ingénieurs en sécurité des applications peuvent-ils vous aider ? Ils ont un rôle important à jouer : celui d’évaluer les applications afin de garantir qu’elles ne sont pas vulnérables aux attaques dues à une authentification défaillante. Dans cette optique, les ingénieurs en sécurité des applications recherchent la présence des faiblesses suivantes.
Présence de mots de passe par défaut, faibles ou bien connus
Les ingénieurs vérifient que l’application n’a pas recours à des identifiants par défaut (tels que admin/admin pour les comptes d’administration). Ils analysent l’application à la recherche de mots de passe faibles, exigent que les utilisateurs créent des mots de passe avec un certain nombre de caractères, dont des caractères spéciaux, et n’autorisent pas l’utilisation des mots de passe courants. Le National Institute of Standards and Technology (NIST) a élaboré des lignes directrices relatives à la longueur, la complexité et la rotation des mots de passe.
Authentification fondée sur des informations connues
Souvent, les sites Web permettent aux utilisateurs de réinitialiser un mot de passe à l’aide de questions d’authentification fondées sur des informations qu’ils connaissent, telles que le nom de la rue où ils ont grandi ou le nom de leur chien. Le problème de cette approche est qu’une grande partie de ces informations personnelles peuvent être obtenues par le biais des profils et de l’activité d’une personne sur les réseaux sociaux ou sur le Dark Web si celles-ci ont déjà été compromises.
Les ingénieurs en sécurité des applications implémentent des mécanismes de récupération de compte plus robustes que l’authentification fondée sur des informations connues, par exemple en exigeant qu’un code soit envoyé à une adresse e-mail ou à un numéro de téléphone enregistré auquel l’utilisateur a accès. Ils limitent et retardent également les tentatives de connexion échouées pour empêcher les attaquants d’utiliser des attaques par force brute et par dictionnaire pour deviner les mots de passe. En outre, ils s’assurent que l’application alerte les administrateurs en cas d’échecs de connexion.
Mots de passe en texte brut ou ayant un hachage faible
Stocker les mots de passe en texte brut et permettre aux utilisateurs de les saisir sous ce même format signifie que des personnes malveillantes peuvent facilement les lire. Les ingénieurs en sécurité des applications s’assurent que tous les mots de passe permettant d’accéder aux ressources des applications font l’objet d’un salage et d’un hachage. Ces termes, qui semblent sortir tout droit d’un livre de recettes, signifient que des données supplémentaires sont ajoutées aux mots de passe et que ceux-ci sont brouillés de manière irréversible.
De cette façon, même si une personne vole un mot de passe, elle ne pourra pas l’utiliser. Certains algorithmes informatiques (tels que MD5) utilisés pour hacher les mots de passe sont considérés comme faibles, car ils peuvent rapidement faire l’objet d’une démarche d’ingénierie inverse. Les ingénieurs en sécurité des applications évitent d’utiliser ces algorithmes et recourent à la place à des algorithmes de hachage puissants.
Authentification à facteur unique
Le fait de n’utiliser qu’un nom d’utilisateur et un mot de passe (un élément que l’utilisateur connaît) est appelé authentification à facteur unique. Étant donné qu’un attaquant peut deviner ou voler des mots de passe, les ingénieurs en sécurité des applications implémentent l’authentification multifacteur (MFA) partout où cela est possible pour protéger le processus d’authentification au sein des applications.
La MFA emploie à la fois un élément que l’utilisateur connaît (comme un mot de passe) et un élément qu’il possède (comme un téléphone) ou un élément qui lui est unique (comme son visage ou ses empreintes digitales). Par exemple, imaginons qu’un utilisateur saisisse son nom d’utilisateur et son mot de passe dans une application. Une demande d’authentification distincte, qu’il doit également approuver, est envoyée sur son téléphone mobile. Ce niveau de sécurité supplémentaire rend plus difficile la compromission des comptes par les attaquants.
Gestion inappropriée des ID de session et des jetons
Une mauvaise gestion des ID de session et des jetons peut permettre à un attaquant de détourner une session et d’usurper l’identité d’une victime. Afin de protéger les ID de session contre le piratage, les ingénieurs prennent un certain nombre de mesures. Ils s’assurent que les noms des ID ne sont pas évocateurs, afin que les attaquants ne puissent pas obtenir d’informations sur les technologies et les langages de programmation utilisés par l’application.
Tout comme les mots de passe, les ID de session doivent être suffisamment longs pour empêcher les attaques par force brute. De plus, ils doivent être imprévisibles, de sorte qu’un attaquant soit incapable de les deviner. Les ingénieurs en sécurité des applications stockent par ailleurs la signification ou la logique métier des ID de session côté serveur (et non côté client, où l’utilisateur peut y avoir accès).
Enfin, les ingénieurs en sécurité des applications implémentent des outils de gestion de session intégrés plutôt que d’en créer de nouveaux de toutes pièces et sont conscients des vulnérabilités du cadre qu’ils choisissent d’utiliser. Pour plus d’informations sur la gestion des sessions, consultez l’aide-mémoire OWASP correspondant.
Une session est une série de requêtes et de réponses envoyées à une application qui sont associées à un utilisateur donné. Les ID de session établissent les droits d’accès aux interactions des utilisateurs pour la durée de la session.
Protection contre les contrôles d’accès défaillants
Alors que l’authentification permet à un utilisateur de se connecter à un compte, le contrôle d’accès applique des politiques d’autorisations utilisateur. Lorsque celui-ci est défaillant, les attaquants trouvent des moyens de consulter ou de modifier les comptes d’une autre personne ou d’agir en tant qu’administrateurs, en utilisant des fonctions privilégiées pour accéder à des enregistrements, les modifier ou les supprimer. Il s’agit d’une faille de sécurité courante et son impact peut être grave suivant les types de données auxquels les attaquants arrivent à accéder.
Les ingénieurs en sécurité des applications protègent les applications contre ce risque en utilisant plusieurs stratégies.
- Refus par défaut : si une demande n’est pas spécifiquement autorisée, elle est refusée. Par exemple, si un administrateur crée un nouveau compte utilisateur, ce compte doit disposer par défaut de droits d’accès minimaux ou inexistants jusqu’à ce que ceux-ci soient configurés.
- Moindre privilège : tous les utilisateurs disposent d’un accès aussi limité que possible.
- Application du principe de propriété des enregistrements : seuls certains utilisateurs peuvent créer, consulter, mettre à jour ou supprimer chaque enregistrement donné.
- Consignation des échecs du contrôle d’accès : lorsqu’un mot de passe incorrect est saisi, un enregistrement est créé et les administrateurs sont alertés.
- Gestion des jetons : des délais d’expiration des jetons sont définis, et, lors de la connexion, les jetons stockés sont supprimés. Cela permet d’éviter que les jetons ne soient utilisés indéfiniment et qu’un attaquant n’altère ceux-ci pour élever ses privilèges.
- Réalisation précoce et fréquente de tests : enfin, l’ingénieur en sécurité des applications teste ces protections du contrôle d’accès pendant la procédure d’assurance qualité et tout au long du SDLC.
Conclusion
Vous avez découvert les stratégies utilisées par les ingénieurs en sécurité des applications pour protéger les fonctions d’authentification et de contrôle d’accès d’une application, qui permettent de garantir que seuls les utilisateurs légitimes puissent accéder aux ressources et fonctionnalités qui leur sont attribuées. Il est maintenant temps d’aborder une dernière considération relative à la protection des applications : garantir que les données sensibles ne sont pas exposées.
