Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
Ce papier présente une analyse empirique à grande échelle de 107 rapports de bug bounty classifiés, révélant que la famille de vulnérabilités BOLA au niveau des actions est dominante mais sous-représentée, et démontrant que la dépendance aux balises de la plateforme surestime considérablement la prévalence de l'autorisation de niveau d'objet brisée.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous marchez dans un complexe d'appartements massif et haute technologie. Vous possédez une carte d'accès qui vous permet d'entrer dans le bâtiment (authentification), mais la véritable sécurité devrait consister à vérifier quel appartement spécifique vous êtes autorisé à entrer.
La Violation de l'autorisation au niveau des objets (BOLA) se produit lorsque le gardien de sécurité du bâtiment oublie de vérifier votre carte d'accès par rapport au numéro d'appartement spécifique que vous tentez d'ouvrir. Vous pourriez être un résident valide, mais vous essayez d'ouvrir l'appartement 402, et le gardien dit simplement : « Bien sûr, allez-y », sans vérifier si le 402 vous appartient.
Ce document est une vaste enquête sur 107 rapports de sécurité réels issus d'un programme de bug bounty (où les pirates sont payés pour trouver ces failles). Les chercheurs voulaient dépasser les conseils de sécurité « théoriques » et examiner ce qui se passe réellement dans le monde réel.
Voici la répartition de leurs découvertes, utilisant des analogies simples :
1. Le problème du « bruit d'étiquettes » (Les fausses alertes)
Les chercheurs ont commencé par examiner 200 rapports étiquetés « IDOR » (un nom courant pour ce type de bug) sur HackerOne.
- La découverte : Seuls 42 % de ces rapports étaient réellement du vrai matériel.
- L'analogie : Imaginez un système d'alarme incendie qui se déclenche 200 fois. Les chercheurs ont constaté que 39 % du temps, ce n'était pas un incendie du tout — c'était simplement quelqu'un qui brûlait du pain, une douche très chaude ou un capteur défectueux.
- À retenir : Le fait qu'un système soit étiqueté « IDOR » ne signifie pas qu'il présente la vulnérabilité spécifique et dangereuse de « Broken Object ». Les équipes de sécurité surestiment souvent le risque car elles font trop confiance aux étiquettes.
2. Les deux principaux méchants (La taxonomie)
Les chercheurs ont classé les vrais bugs en six catégories. Deux d'entre elles étaient les grands gagnants, représentant près de 80 % de tous les cas :
Méchant A : La « Référence directe d'objet » (L'astuce de l'annuaire téléphonique)
- De quoi il s'agit : Vous voyez une URL comme
website.com/facture/101. Vous changez le numéro en102, et soudainement, vous voyez la facture de quelqu'un d'autre. - L'analogie : C'est comme vous promener devant une rangée de boîtes aux lettres. Vous savez que votre boîte est la n° 101. Vous essayez la 102, et la serrure est cassée, vous l'ouvrez donc et lisez le courrier de votre voisin.
- Fréquence : Cela s'est produit dans 37 % des cas.
- De quoi il s'agit : Vous voyez une URL comme
Méchant B : L'« Objet au niveau de l'action » (Le vandale)
- De quoi il s'agit : C'est la grande surprise. Il ne s'agit pas seulement de lire les données de quelqu'un d'autre ; il s'agit de les modifier ou de les supprimer.
- L'analogie : Vous vous approchez de la boîte aux lettres de votre voisin (que vous ne devriez pas toucher), et au lieu de simplement lire le courrier, vous arrachez la boîte aux lettres du mur, supprimez ses e-mails ou transfèrent son argent.
- Fréquence : Cela s'est produit dans 42 % des cas.
- Pourquoi cela compte : La plupart des guides de sécurité se concentrent sur la « lecture » des données. Ce document dit : « Hé, les méchants détruisent et modifient en fait les données plus souvent qu'ils ne les espionnent. »
3. Les autres méchants sournois
Les 20 % restants de bugs étaient plus complexes :
- Isolation des locataires : Vous êtes dans un immeuble de bureaux partagé. Vous essayez d'ouvrir la porte de la suite de bureaux d'une autre entreprise, et la serrure échoue.
- Contexte de flux de travail : Vous avez été licencié d'une entreprise, mais le système vous permet toujours d'accéder aux fichiers « archivés » d'un projet sur lequel vous travailliez auparavant, car le système a oublié de mettre à jour votre statut.
- Divulgation en chaîne : Vous ne pouvez pas deviner l'identifiant, mais vous trouvez une liste d'identifiants dans une autre partie de l'application (comme un reçu) et utilisez cette liste pour pénétrer dans les comptes d'autres personnes.
- Rattachement d'objet : Vous trompez le système pour qu'il pense que vous possédez l'objet en modifiant un champ caché dans la requête (comme changer le nom du « Propriétaire » sur un document).
4. La surprise « verticale » (Le trajet en ascenseur)
Habituellement, nous considérons ces attaques comme « horizontales » (l'utilisateur A vole à l'utilisateur B).
- La découverte : 12 % du temps, un utilisateur ordinaire a réussi à accéder ou à supprimer des éléments appartenant à un administrateur.
- L'analogie : Un locataire ordinaire du complexe d'appartements parvient à entrer dans le bureau privé du gestionnaire du bâtiment et à supprimer les clés maîtresses.
- À retenir : C'est un risque énorme que la plupart des listes de contrôle de sécurité ignorent, car elles supposent que « les administrateurs sont sûrs ».
5. Les IDs « magiques » ne fonctionnent pas
Les développeurs pensent souvent : « Si nous n'utilisons pas de nombres simples comme 1, 2, 3, mais plutôt de longs codes aléatoires (UUID) ou des chaînes encodées, nous sommes en sécurité. »
- La découverte : 39 % des attaques réussies ont utilisé ces IDs « complexes ».
- L'analogie : Les méchants ont trouvé un moyen de décoder le « code secret » sur la boîte aux lettres, ont réalisé qu'il s'agissait simplement d'un numéro caché, puis ont simplement incrémenté le numéro pour accéder à la boîte aux lettres suivante.
- À retenir : Cacher l'ID ne résout pas le problème. Le serveur doit toujours vérifier si vous possédez l'objet, indépendamment de l'apparence de l'ID.
6. La faille « GraphQL »
Le document a révélé que de nombreuses applications modernes utilisent un système appelé GraphQL. Ces systèmes utilisent des « IDs globaux » (comme gid://hackerone/Report/123).
- La découverte : Les attaquants ont constaté que s'ils décodaient ces IDs, ils révélaient les numéros séquentiels sous-jacents, leur permettant de deviner facilement l'ID suivant.
- À retenir : Le fait qu'un ID ressemble à une chaîne complexe de caractères ne signifie pas qu'il est aléatoire.
Résumé pour le citoyen ordinaire
Ce document nous dit que :
- Ne faites pas confiance aux étiquettes : Le fait qu'un système soit signalé comme ayant un bug spécifique ne signifie pas qu'il est réellement cassé de cette manière précise.
- Les méchants sont destructeurs : Ils ne volent pas seulement des données ; ils les suppriment et les modifient plus souvent que nous ne le pensions.
- Les codes secrets ne suffisent pas : L'utilisation d'IDs complexes n'arrête pas les pirates si le serveur ne vérifie pas qui possède les données.
- Les utilisateurs ordinaires peuvent nuire aux administrateurs : Un compte utilisateur normal peut parfois pénétrer dans les affaires du « patron ».
Le document conclut que les tests de sécurité doivent changer. Nous devons cesser de vérifier uniquement si vous pouvez lire les données de quelqu'un d'autre et commencer à vérifier si vous pouvez les supprimer ou les modifier, et nous devons tester si les utilisateurs ordinaires peuvent accidentellement (ou intentionnellement) pénétrer dans les affaires de l'administrateur.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.