Les API exposent souvent des points d'accès (endpoints) qui gèrent les identifiants d'objets, créant une vaste surface d'attaque potentielle. L'autorisation au niveau de l'objet est un mécanisme de contrôle d'accès généralement mis en œuvre au niveau du code pour valider la capacité d'un utilisateur à accéder à un objet donné. Les mécanismes d'autorisation et de contrôle d'accès dans les applications modernes sont complexes et répandus. Même si une application met en œuvre une infrastructure appropriée pour les vérifications d'autorisation, les développeurs oublient souvent d'appliquer ces vérifications avant d'accéder à un objet.
Les attaquants peuvent facilement exploiter les points d'accès (endpoints) d'API vulnérables à l' autorisation au niveau de l'objet défaillante (BOLA) en manipulant l'identifiant d'un objet qui est envoyé dans une requête API. Ceci est dû au fait que le composant serveur ne suit généralement pas entièrement l'état du client. Au lieu de cela, le composant serveur s'appuie généralement sur des paramètres tels que les identifiants d'objets envoyés par le client, pour décider quels objets peuvent être consultés.
Les vulnérabilités BOLA sont présentes dans environ 40 % de toutes les attaques d'API et sont répertoriées comme la menace numéro un pour la sécurité des API dans le OWASP API Security Top 10. Tout accès à des données non autorisées est grave, quelle que soit sa classification ou sa sensibilité. Malheureusement, ces types de failles d'autorisation ne sont pas facilement détectables par des tests statiques ou dynamiques automatisés.
Chaque point d'accès (endpoint) d'API qui reçoit l'identifiant d'un objet et effectue tout type d'action sur cet objet devrait implémenter des vérifications d'autorisation au niveau de l'objet. Ces vérifications devraient être effectuées en continu tout au long d'une session donnée pour valider que l'utilisateur connecté a l'accès nécessaire pour effectuer l'action demandée sur l'objet demandé.
Quel est l'impact potentiel d'une attaque BOLA ?
Le défaut d'application de l'autorisation au niveau de l'objet peut entraîner l'exfiltration de données ainsi que la consultation, la modification ou la destruction non autorisées de données. La BOLA peut également entraîner une prise de contrôle totale de compte , comme dans les cas où un attaquant peut compromettre un processus de réinitialisation de mot de passe et réinitialiser les identifiants d'un compte auquel il n'est pas autorisé.
Dans l'exemple ci-dessus, la logique backend de l'application interroge la base de données avec le userId dans le paramètre de requête tout en vérifiant l'autorisation avec le userId dans le cookie. Dans des conditions normales, ces deux valeurs devraient correspondre. Cependant, un attaquant pourrait simplement modifier la valeur du userId dans le paramètre de requête afin d'accéder à des données non autorisées.
Si les userIds sont séquentiels, l'attaquant peut simplement énumérer la valeur du userId dans le paramètre de requête pour récupérer, ou exfiltrer, de grandes quantités de données, en particulier si les limites de débit ne sont pas appliquées.
Exemples concrets de vulnérabilités d'autorisation au niveau de l'objet défaillante (BOLA)
Comment un hacker aurait pu prendre le contrôle de votre compte Uber
En 2019, un chercheur en sécurité a révélé une vulnérabilité BOLA qui aurait permis à un attaquant de prendre le contrôle de n'importe quel compte utilisateur sur Uber. En exploitant cette vulnérabilité, l'attaquant pouvait accéder au compte d'un autre utilisateur pour suivre la localisation de l'utilisateur ciblé, commander des courses, et plus encore. L'attaquant pouvait également exploiter la vulnérabilité BOLA pour collecter des jetons d'accès de l'application mobile Uber, puis utiliser ces jetons d'accès pour prendre le contrôle des comptes Uber Driver et Uber Eats. Le userId de l'application Uber pouvait être facilement énuméré en fournissant le numéro de téléphone ou l'adresse e-mail d'un utilisateur dans une autre requête API.
L'attaque BOLA à la Banque Centrale de Russie
Un exemple marquant d'attaque BOLA réussie s'est produit à la Banque Centrale de Russie en 2016, où des attaquants ont réussi à modifier un identifiant de compte et à effectuer des transferts non autorisés vers d'autres comptes via un système de paiements rapides, parvenant à voler environ 2 milliards de roubles.
Dans ce cas, les attaquants ont réussi à obtenir des données de compte client en exploitant la vulnérabilité BOLA, puis ont lancé l'application mobile de la banque en mode débogage, se sont connectés en tant que client réel et ont transféré des fonds vers une autre banque. Avant d'effectuer le virement, l'attaquant a modifié l'identifiant du compte par celui d'un autre client, permettant ainsi le traitement du virement sans vérification d'identité adéquate.
Pourquoi les outils existants ne parviennent pas à vous protéger contre les vulnérabilités BOLA
Les contrôles de sécurité traditionnels tels que les WAF et les passerelles API ne détectent pas ces types d'attaques car ils ne comprennent pas le contexte des API et n'établissent pas de référence pour l'utilisation normale des API.
En ce qui concerne les vulnérabilités BOLA, ces outils ne savent pas que l'identifiant utilisateur (userId) dans le paramètre de requête et l'identifiant utilisateur (userId) dans le cookie devraient correspondre. De plus, comme il ne s'agit pas d'un modèle d'attaque connu et prévisible, comme une injection de code où la correspondance de motifs de base et le filtrage de messages peuvent être employés, une attaque BOLA ne peut pas être identifiée par les signatures utilisées par un WAF ou une passerelle API.
Comment protéger les API contre les attaques par autorisation au niveau de l'objet brisée (BOLA)
Afin de prévenir les attaques BOLA, une solution de sécurité API doit être capable d'apprendre la logique métier d'une API et de détecter lorsqu'un utilisateur authentifié tente d'obtenir un accès non autorisé aux données d'un autre utilisateur. Concrètement, l'outil de sécurité API doit être capable de reconnaître que les deux objets doivent correspondre et que l'utilisateur authentifié est autorisé à accéder à l'objet demandé. Ce type de détection nécessite l'analyse de grandes quantités de trafic API afin d'acquérir du contexte et de comprendre le comportement normal de chaque API.
Seule une solution qui établit une référence d'utilisation normale peut identifier un comportement anormal, comme un attaquant manipulant l'identifiant utilisateur (userId) dans un paramètre de requête dans les requêtes GET, ou une variable userId dans le corps d'un message de requêtes POST.
Pour découvrir comment la plateforme Salt peut vous aider à prévenir les attaques BOLA, demandez une démo dès aujourd'hui.