L'authentification dans les API est un sujet complexe, sur lequel les ingénieurs logiciels et les experts en sécurité ont souvent des idées reçues quant à ses limites et à sa mise en œuvre correcte. Pour compliquer encore les choses, il n'est pas toujours possible de demander des identifiants ou des facteurs d'authentification supplémentaires aux utilisateurs ou aux machines dans le cadre d'une communication API directe. De plus, les mécanismes d'authentification sont des cibles faciles pour les attaquants, surtout s'ils sont entièrement exposés ou publics. Ces deux points rendent le composant d'authentification potentiellement vulnérable à des attaques avancées, notamment la force brute, le credential stuffing et le cassage d'identifiants.
Les problèmes d'authentification dans les API découlent généralement de deux causes :
- Absence de mécanismes de protection — Les points de terminaison d'API dédiés à l'authentification doivent être traités différemment des points de terminaison classiques et bénéficier de couches de protection supplémentaires.
- Mauvaise implémentation du mécanisme — Le mécanisme est utilisé ou mis en œuvre sans tenir compte des vecteurs d'attaque, ou il n'est pas adapté au cas d'usage. Par exemple, un mécanisme d'authentification conçu pour des appareils IoT n'est généralement pas le choix approprié pour une application web telle qu'un site e-commerce.
Plusieurs facteurs techniques conduisent également à une authentification défaillante dans les API. Voici les plus courants :
- Complexité insuffisante des mots de passe.
- Historique des mots de passe court ou inexistant.
- Seuils de verrouillage de compte excessivement élevés ou absents.
- Défaut de provisionnement de certificats uniques par appareil dans le cadre d'une authentification par certificat.
- Durées de rotation des mots de passe et des certificats excessivement longues.
- Données d'authentification exposées dans les URL et les requêtes GET.
- Jetons d'authentification avec une entropie insuffisante.
- Utilisation de clés API comme seul élément d'authentification.
- Défaut de validation de l'authenticité des données d'authentification.
- Configuration non sécurisée des jetons JSON Web (JWT), telle que l'utilisation d'un algorithme de signature numérique faible ou l'absence de signature.
- Utilisation de clés de petite taille dans les algorithmes de chiffrement ou de hachage.
- Utilisation de chiffrements faibles ou obsolètes.
- Utilisation d'algorithmes inadaptés au cas d'usage, comme l'emploi d'algorithmes de hachage au lieu de fonctions de dérivation de clé basées sur un mot de passe (PBKDF).
- Absence de renforcement de l'authentification lorsque les flux d'authentification sont ciblés, par exemple en ne proposant pas de défi dynamique via CAPTCHA ou une authentification à deux facteurs (2FA).
Impact potentiel d'une attaque par authentification défaillante
Un attaquant parvenant à exploiter les vulnérabilités des mécanismes d'authentification peut prendre le contrôle de comptes utilisateurs, accéder sans autorisation aux données d'un autre utilisateur ou effectuer des transactions non autorisées en usurpant son identité.
Les API peuvent être conçues explicitement pour la communication entre machines ou pour une communication API directe. Un attaquant qui compromet ce mécanisme d'authentification ou cette session authentifiée peut potentiellement accéder à toutes les données auxquelles cette identité machine a droit. Il existe également des variantes de ce type d'attaque dans les conceptions cloud-native, impliquant la compromission de l'authentification des charges de travail et des services de métadonnées d'API côté serveur.
À quoi ressemble une attaque par authentification défaillante ?
L'authentification défaillante est la deuxième menace la plus critique pour la sécurité des API répertoriée dans le OWASP API Security Top 10. Les exemples courants d'attaques ciblant une authentification défaillante incluent l'énumération d'API et les attaques par force brute qui effectuent un volume élevé de requêtes API avec des modifications mineures. Ces attaques peuvent également cibler une authentification rompue ou faible.
Par exemple, les mécanismes de récupération de mot de passe envoient souvent un SMS au téléphone de l'utilisateur contenant un jeton de réinitialisation composé d'une série de chiffres. Un attaquant peut lancer une réinitialisation de mot de passe et, si l'API ne met pas en œuvre de limitation de débit, il peut énumérer (ou « deviner ») le jeton de réinitialisation jusqu'à obtenir une réponse positive. Selon le débit du point de terminaison de l'API cible, un attaquant peut être en mesure de tester des milliers, voire des millions de combinaisons en quelques minutes.
Par exemple, les mécanismes de récupération de mot de passe envoient souvent un SMS au téléphone de l'utilisateur contenant un jeton de réinitialisation composé d'une série de chiffres. Un attaquant peut lancer une réinitialisation de mot de passe et, si l'API ne met pas en œuvre de limitation de débit, il peut énumérer (ou « deviner ») le jeton de réinitialisation jusqu'à obtenir une réponse positive. Selon le débit du point de terminaison de l'API cible, un attaquant peut être en mesure de tester des milliers, voire des millions de combinaisons en quelques minutes.
Exemple concret : la violation de données de Parler
En 2021, l'analyse par Salt de la violation de données de Parler a révélé que l'authentification de la plateforme de médias sociaux était au moins partiellement absente, confirmant le consensus général parmi les hacktivistes et les médias. Cette faille, associée à d'autres vulnérabilités de sécurité sur la plateforme Parler, a permis le scraping d'au moins 70 To de données avant que la plateforme ne soit fermée le 11 janvier 2021, lorsqu'il est apparu clairement que les participants à l'assaut du Capitole, six jours plus tôt, l'avaient utilisée pour coordonner leurs activités.
Les hacktivistes ont découvert qu'au moins un point de terminaison d'API était accessible sans aucune exigence d'authentification et que plusieurs API permettaient un accès direct aux informations de profil des utilisateurs de Parler ainsi qu'à leur contenu, notamment les messages, les images et les vidéos. Il est peu probable que Parler ait eu l'intention de configurer ces API et ces pages pour qu'elles soient accessibles sans authentification.
Certains rapports ont fait état d'une mauvaise configuration de sécurité résultant d'une intégration Twilio, laquelle a été désactivée par la suite. Selon certaines allégations, des hacktivistes ayant participé au scraping des données de la plateforme auraient utilisé cette faille pour contourner l'authentification multifacteur (MFA) lors de la création de comptes et extraire des données. Ces affirmations ont été contestées par les hacktivistes eux-mêmes, et les représentants de Twilio ont également déclaré qu'elles étaient fausses. Une mauvaise configuration du MFA alimenterait davantage le débat sur le caractère réellement public des données de Parler, mais il n'existe pas suffisamment de preuves médico-légales pour étayer l'une ou l'autre de ces thèses.
La plupart des médias ont attribué les problèmes de sécurité de Parler à un mauvais codage. Bien que des choix de conception et des modèles de codage médiocres aient très probablement joué un rôle, qualifier les problèmes ayant mené à la violation de Parler de simple « mauvais codage » ne fait qu'entretenir les tensions entre les développeurs, les ingénieurs et les experts en sécurité.
Le développement d'applications et la conception de systèmes modernes sont d'une complexité extrême et exigent que de nombreux acteurs, qu'ils occupent des fonctions liées à la sécurité ou non, travaillent en parfaite synchronisation pour assurer le bon fonctionnement d'une application à grande échelle. Le problème est aggravé par la chaîne d'approvisionnement numérique moderne et le fait que les organisations externalisent des éléments informatiques en bloc ou par projet. Les bugs et les vulnérabilités sont inévitables. Cependant, nous pouvons continuer à tirer des leçons de ces erreurs pour améliorer l'état de la sécurité des applications et des API.
Pourquoi les outils existants ne parviennent pas à protéger les API contre les failles d'authentification
Les contrôles de sécurité traditionnels, tels que les WAF, n'appliquent généralement pas l'authentification à un niveau granulaire et se contentent souvent de vérifier la présence d'un identifiant de session ou d'un jeton d'authentification dans une requête donnée. Les passerelles d'API peuvent appliquer l'authentification dans le cadre des politiques de contrôle d'accès à la gestion des API, mais cela suppose que les équipes responsables aient défini ces politiques de manière appropriée.
Il existe souvent une rupture opérationnelle entre les équipes qui créent les API, celles qui les publient et celles qui sécurisent les API. Quoi qu'il en soit, les passerelles d'API ne sont pas en mesure de déterminer quelle authentification est appropriée pour une API dans un cas d'utilisation donné.
Les contrôles de sécurité traditionnels manquent également de capacités pour suivre le trafic d'attaque dans la durée, ce qui est pourtant nécessaire pour décrypter les différentes formes d'attaques avancées ciblant l'authentification, telles que le credential stuffing et le craquage d'identifiants. Ils se basent souvent sur des taux de consommation d'API excessifs pour identifier les tentatives d'attaques par force brute élémentaires.
Comment protéger vos API contre les attaques par faille d'authentification
Pour se protéger contre les attaques par faille d'authentification, une solution de sécurité des API doit être capable de profiler la séquence d'authentification type pour chaque flux d'API. La solution peut alors détecter des comportements anormaux tels que des identifiants manquants, des facteurs d'authentification absents ou des appels d'authentification hors séquence. L'établissement d'une base de référence et l'identification de comportements anormaux ne peuvent se faire qu'en analysant de grandes quantités de trafic API en production. Cette forme d'analyse est essentielle pour atténuer les attaques avancées ciblant l'authentification, comme le credential stuffing et le craquage d'identifiants.
Pour en savoir plus sur la façon dont Salt peut aider à protéger votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.