Principales vulnérabilités de l'API OATH
Principales vulnérabilités de l'API OATH : introduction
En ce qui concerne les exploits, les API sont le meilleur point de départ. API l'accès se compose généralement de trois parties. Les clients reçoivent des jetons par un serveur d'autorisation, qui s'exécute parallèlement aux API. L'API reçoit des jetons d'accès du client et applique des règles d'autorisation spécifiques au domaine en fonction de ceux-ci.
Les applications logicielles modernes sont vulnérables à une variété de dangers. Tenez-vous au courant des exploits et des failles de sécurité les plus récents ; avoir des repères pour ces vulnérabilités est essentiel pour assurer la sécurité des applications avant qu'une attaque ne se produise. Les applications tierces s'appuient de plus en plus sur le protocole OAuth. Grâce à cette technologie, les utilisateurs bénéficieront d'une meilleure expérience utilisateur globale, ainsi que d'une connexion et d'une autorisation plus rapides. Elle peut être plus sécurisée que l'autorisation conventionnelle puisque les utilisateurs n'ont pas à divulguer leurs informations d'identification avec l'application tierce pour accéder à une ressource donnée. Bien que le protocole lui-même soit sûr et sécurisé, la façon dont il est mis en œuvre peut vous exposer à des attaques.
Lors de la conception et de l'hébergement d'API, cet article se concentre sur les vulnérabilités OAuth typiques, ainsi que sur diverses mesures de sécurité.
Autorisation au niveau de l'objet cassé
Il existe une vaste surface d'attaque si l'autorisation est violée puisque les API permettent d'accéder aux objets. Étant donné que les éléments accessibles par l'API doivent être authentifiés, cela est nécessaire. Implémentez des vérifications d'autorisation au niveau de l'objet à l'aide d'une passerelle API. Seuls ceux qui disposent des informations d'identification d'autorisation appropriées doivent être autorisés à accéder.
Authentification utilisateur cassée
Les jetons non autorisés sont un autre moyen fréquent pour les attaquants d'accéder aux API. Les systèmes d'authentification peuvent être piratés ou une clé API peut être exposée par erreur. Les jetons d'authentification peuvent être utilisé par les pirates pour acquérir l'accès. Authentifiez les personnes uniquement si elles sont dignes de confiance et utilisez des mots de passe forts. Avec OAuth, vous pouvez aller au-delà des simples clés API et accéder à vos données. Vous devriez toujours penser à la façon dont vous allez entrer et sortir d'un endroit. Les jetons contraints par l'expéditeur OAuth MTLS peuvent être utilisés conjointement avec Mutual TLS pour garantir que les clients ne se comportent pas mal et transmettent les jetons à la mauvaise partie lors de l'accès à d'autres machines.
Promotion API :
Exposition excessive de données
Il n'y a aucune contrainte sur le nombre d'endpoints pouvant être publiés. La plupart du temps, toutes les fonctionnalités ne sont pas disponibles pour tous les utilisateurs. En exposant plus de données qu'il n'est absolument nécessaire, vous vous mettez vous-même et les autres en danger. Évitez de divulguer des informations sensibles d'information jusqu'à ce que cela soit absolument nécessaire. Les développeurs peuvent spécifier qui a accès à quoi en utilisant les champs d'application et les revendications OAuth. Les revendications peuvent spécifier à quelles sections des données un utilisateur a accès. Le contrôle d'accès peut être rendu plus simple et plus facile à gérer en utilisant une structure standard pour toutes les API.
Manque de ressources et limitation des taux
Les chapeaux noirs utilisent souvent des attaques par déni de service (DoS) comme moyen de force brute pour submerger un serveur et ainsi réduire sa disponibilité à zéro. En l'absence de restrictions sur les ressources pouvant être appelées, une API est vulnérable à une attaque débilitante. 'À l'aide d'une passerelle API ou d'un outil de gestion, vous pouvez définir des restrictions de débit pour les API. Le filtrage et la pagination doivent être inclus, ainsi que les réponses restreintes.
Mauvaise configuration du système de sécurité
Les différentes directives de configuration de la sécurité sont assez complètes, en raison de la forte probabilité de mauvaise configuration de la sécurité. Un certain nombre de petites choses peuvent compromettre la sécurité de votre plateforme. Il est possible que des black hats avec des buts inavoués découvrent des informations sensibles envoyées en réponse à des requêtes malformées, par exemple.
Affectation en masse
Ce n'est pas parce qu'un point de terminaison n'est pas défini publiquement qu'il n'est pas accessible aux développeurs. Une API secrète peut être facilement interceptée et rétro-conçue par des pirates. Jetez un œil à cet exemple de base, qui utilise un Bearer Token ouvert dans une API "privée". D'autre part, une documentation publique peut exister pour quelque chose qui est exclusivement destiné à un usage personnel. Les informations exposées peuvent être utilisées par les black hats non seulement pour lire mais aussi pour manipuler les caractéristiques des objets. Considérez-vous comme un hacker lorsque vous recherchez des points faibles potentiels dans vos défenses. N'autorisez que les personnes disposant des droits appropriés à accéder à ce qui a été renvoyé. Pour minimiser la vulnérabilité, limitez le package de réponse de l'API. Les répondants ne doivent pas ajouter de liens qui ne sont pas absolument nécessaires.
API promue :
Mauvaise gestion des actifs
En plus d'améliorer la productivité des développeurs, les versions et la documentation actuelles sont essentielles pour votre propre sécurité. Préparez-vous longtemps à l'avance à l'introduction de nouvelles versions et à l'abandon des anciennes API. Utilisez les API les plus récentes au lieu d'autoriser les anciennes à rester utilisées. Une spécification d'API pourrait être utilisée comme source principale de vérité pour la documentation.
Injection
Les API sont vulnérables à l'injection, tout comme les applications de développement tierces. Un code malveillant peut être utilisé pour supprimer des données ou voler des informations confidentielles, telles que des mots de passe et des numéros de carte de crédit. La leçon la plus importante à en tirer est de ne pas dépendre des paramètres par défaut. Votre fournisseur de gestion ou de passerelle doit être en mesure de répondre à vos besoins d'application uniques. Les messages d'erreur ne doivent pas contenir d'informations sensibles. Pour empêcher les données d'identité de fuir en dehors du système, les pseudonymes par paires doivent être utilisés dans les jetons. Cela garantit qu'aucun client ne peut travailler ensemble pour identifier un utilisateur.
Journalisation et surveillance insuffisantes
Lorsqu'une attaque a lieu, les équipes ont besoin d'une stratégie de réaction bien pensée. Les développeurs continueront d'exploiter les vulnérabilités sans se faire prendre si un système de journalisation et de surveillance fiable n'est pas en place, ce qui augmentera les pertes et nuira à la perception que le public a de l'entreprise. Adoptez une stratégie stricte de surveillance des API et de test des terminaux de production. Les testeurs de chapeau blanc qui trouvent des vulnérabilités dès le début devraient être récompensés par un programme de primes. La trace du journal peut être améliorée en incluant l'identité de l'utilisateur dans les transactions API. Assurez-vous que toutes les couches de votre architecture d'API sont auditées à l'aide des données de jeton d'accès.
Conclusion
Les architectes de plate-forme peuvent équiper leurs systèmes pour garder une longueur d'avance sur les attaquants en suivant des critères de vulnérabilité établis. Étant donné que les API peuvent fournir un accès aux informations d'identification personnelle (PII), le maintien de la sécurité de ces services est essentiel à la fois pour la stabilité de l'entreprise et la conformité à la législation telle que le RGPD. N'envoyez jamais de jetons OAuth directement via une API sans utiliser une passerelle API et l'approche des jetons fantômes.
API promue :
