Top 10 de l’OWASP relatif aux risques de sécurité des API : défaillance de l’autorisation au niveau de l’objet

Bien que la liste pour 2023 n’ait pas encore été finalisée, vous pouvez consulter et commenter les 10 principaux risques liés à la sécurité des API sur le site Github de l’Open Worldwide Application Security Project® (OWASP). Le risque n° 1 de la liste est la défaillance de l’autorisation au niveau de l’objet (BOLA).

La BOLA se produit lorsqu’un pirate informatique réussit à requérir des objets de données dont l’accès devrait être restreint.

Vecteurs d’attaque

Les pirates exploitent les points de terminaison des API en manipulant l’identifiant d’un objet inclus dans une requête, ce qui incite l’API à renvoyer des données sensibles et protégées. Les BOLA peuvent se produire dans des applications où le composant serveur ne suit pas entièrement les différents statuts des clients et s’appuie sur les ID d’objets pour déterminer quels objets sont accessibles.

L’OWASP lui a attribué un score d’exploitabilité de deux, ce qui signifie qu’elle est facilement exploitable par les pirates.

Failles de sécurité

Selon l’OWASP, il s’agit de l’une des attaques les plus courantes et les plus dévastatrices contre les API.

Même si l’application dispose d’une infrastructure adéquate pour vérifier les autorisations, les développeurs oublient parfois de recourir à des contrôles d’autorisation avant d’accéder à des objets sensibles. La détection des contrôles d’accès n’est pas nécessairement sensible aux tests statiques ou dynamiques automatisés, ce qui signifie que les failles peuvent ne pas être détectées.

L’OWASP attribue également la note 3 aux BOLA sur son échelle de prévalence. Cette menace de sécurité concerne un grand nombre de domaines et d’applications.

Impacts sur les entreprises

Chaque fois qu’un accès non autorisé est accordé pour des données sensibles, il y a un risque d’exposition et d’engagement de la responsabilité. L’accès non autorisé à certains objets peut également entraîner d’autres violations, notamment le piratage de compte.

Les exploits BOLA peuvent conduire à :

• Une exposition à grande échelle de dossiers sensibles
• La manipulation des dossiers, y compris la visualisation, la modification ou la suppression
• Élévation de privilèges
• Le piratage total des comptes administrateur

Fonctionnement des attaques BOLA

Les pirates recherchent des systèmes qui utilisent des modèles de codes pour les requêtes. Par exemple, ils peuvent tester les failles BOLA en modifiant les identifiants des utilisateurs ou des objets pour savoir comment l’API réagit. Une fois qu’ils ont trouvé une telle faille et qu’ils y ont accès, les API qui ne disposent pas des protocoles de sécurité adéquats courent un très grand risque. Une fois qu’un pirate accède à l’API, toutes les données sont susceptibles d’être compromises.

Voici comment cela pourrait se traduire dans un scénario réel. Quelqu’un peut accéder au système d’une entreprise, de manière légitime ou illégitime, en utilisant un identifiant client. Une fois l’accès authentifié, l’identité est représentée par un jeton. Lors d’une requête API, ils remplacent l’identifiant client qu’ils ont utilisé pour accéder aux données par l’identifiant d’un autre utilisateur, ce qui leur permet d’accéder aux données personnelles d’un autre utilisateur.

Une fois que les pirates constatent que cela fonctionne, ils peuvent automatiser le processus de substitution des numéros d’identification des clients dans les requêtes ultérieures et exfiltrer d’autres dossiers.

Par exemple, une attaque de type « credential-stuffing » peut être utilisée pour violer une institution financière. En modifiant les identifiants des requêtes, les pirates peuvent accéder à différents comptes utilisateur, voire transférer de l’argent ou rediriger des données vers différents points de terminaison.

L’OWASP prend l’exemple d’un constructeur automobile qui permet de contrôler les véhicules à distance avec une API accessible par le téléphone portable du conducteur et en indiquant le numéro d’identification du véhicule. Un pirate pourrait théoriquement authentifier un dispositif, puis substituer le numéro d’identification d’un autre véhicule, qui est facilement accessible en ligne ou sur le véhicule lui-même. Si l’API ne détecte pas que l’authentification n’appartient pas à son véritable propriétaire, des pirates pourraient être en mesure d’accéder au véhicule, le faire démarrer et le voler.

Exemples concrets

Une telle défaillance serait à l’origine d’une violation des données client chez T-Mobile, qui a touché quelque 2,3 millions d’abonnés en 2018. Une autre attaque basée sur les API pourrait également avoir affecté 37 millions d’utilisateurs de T-Mobile en 2023.

Une vulnérabilité a été découverte dans les API de plateformes de réseaux sociaux appartenant à Facebook et à Parler. Pour Facebook, ces vulnérabilités pourraient permettre à des pirates de créer des publications sur les pages d’autres utilisateurs. Bien que les publications n’étaient pas visibles dans les fils d’actualité, elles étaient accessibles par des liens.

Parler a autorisé l’accès à l’API aux messages publics sans avoir besoin d’une authentification. Les numéros d’identification des publications de Parler étant séquentiels, les pirates pouvaient facilement les remplacer par d’autres. Comme il n’y avait pas de limitation de débit, l’automatisation pouvait extraire des données à un débit extrêmement élevé.

Détection des vulnérabilités BOLA

Selon l’OWASP, BOLA affiche une note de deux en ce qui concerne la détectabilité. L’analyse et le test des API sont les meilleures pratiques pour détecter les vulnérabilités BOLA.

La détection commence par l’évaluation des points de terminaison et des identifiants de l’API.

Les ingénieurs peuvent tester les objets IDS tout au long du cycle de vie de l’API. Par exemple, il est possible de réaliser des tests qui exigent le remplacement des identifiants d’objets, en recherchant des messages d’erreur. Si aucun message d’erreur n’est renvoyé, cela peut indiquer un risque d’exposition. Les objets peuvent également être testés pour les actions de lecture, d’écriture et de suppression. Une combinaison de tests automatisés et de tests de pénétration manuels peut permettre de découvrir les failles BOLA.

Malheureusement, les outils traditionnels tels que les passerelles API et les web application firewalls ne sont généralement pas en mesure de protéger contre les attaques BOLA. Si les passerelles API sont efficaces pour gérer l’authentification, elles ne sont pas en mesure de détecter les requêtes malveillantes. Dans la plupart des cas, ces outils utilisent des signatures pour la détection et ne procèdent à aucune vérification pour les cas inconnus.

Parallèlement, les attaques basées sur l’autorisation au niveau de l’objet peuvent ressembler à des requêtes API normales avec un simple changement d’identifiant. Les systèmes sont parfois incapables de remarquer quoi que ce soit qui sorte de l’ordinaire jusqu’à ce qu’il soit trop tard.

Les équipes de sécurité doivent être attentives aux cas où un grand nombre de requêtes API échouent, en particulier à celles qui comportent des erreurs d’autorisation. Lorsque les pirates recherchent des identifiants d’objets valides, il n’est pas rare de constater des erreurs significatives Non autorisé (401), Introuvable (404) ou Interdit (403). Des requêtes multiples pour des identifiants d’objets à partir du même jeton d’autorisation peuvent également être le signe d’une activité malveillante.

Prévention des vulnérabilités BOLA

L’OWASP propose plusieurs stratégies spécifiques pour aider à prévenir les vulnérabilités BOLA :

• La mise en œuvre de mécanismes d’autorisation adéquats qui s’appuient sur les politiques d’utilisateur et la hiérarchie.
• La randomisation des identifiants d’objets et des identifiants uniques globaux (GUID) pour les dossiers.
• Des mécanismes d’autorisation pour vérifier si les utilisateurs connectés ont le droit d’effectuer les actions prévues sur les enregistrements.
• Tests actifs pour évaluer les mécanismes d’autorisation.

Les BOLA sont un exploit connu depuis quelque temps. Il y a plus de dix ans, une violation de l’API des iPads d’Apple s’est produite par l’intermédiaire d’AT&T, exposant les e-mails de quelque 100 000 utilisateurs, dont des hauts fonctionnaires du gouvernement et des médias. Cependant, l’autorisation non respectée au niveau de l’objet reste en tête de liste des menaces qui pèsent sur la sécurité des API.