Applications, sites et API
Particuliers et entreprisesExploitation d’un défaut de contrôle d’accès
Broken access control / IDOR / BOLA
Un service laisse consulter ou modifier une ressource sans vérifier les droits.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
En consultant une facture, un client obtient celle d’une autre personne après un changement de référence. Il est bien connecté, mais le service a oublié de vérifier à qui appartient le document demandé.
Comment cela fonctionne
Un défaut de contrôle d’accès permet de consulter une ressource ou d’effectuer une action sans disposer de l’autorisation correspondante. Savoir qui est connecté ne suffit pas : le site doit aussi vérifier ce que cette personne a le droit de faire sur chaque objet. Le défaut peut concerner des documents, des fonctions d’administration ou certains champs sensibles d’un formulaire.
- La personne est connectée
Son identité est connue.
- Une ressource est demandée
Document, fonction ou champ.
- Le serveur oublie de vérifier les droits
Il livre le document d’un autre utilisateur.
Ce que vous pouvez faire
Vos premiers réflexes
Si vous voyez le dossier d’un autre client, ne poursuivez pas l’exploration. Signalez au service la référence de votre demande sans diffuser le document reçu.
Si vous êtes responsable du service ou de l’organisation
Développeurs : contrôlez le droit sur chaque objet et chaque action côté serveur. Testez avec plusieurs comptes de même rôle et d’organisations différentes, caches compris.
Masquer un bouton dans l’interface ne protège pas l’action qu’il déclenche.
À vous de décider
Le bouton d’administration est masqué. L’action correspondante est-elle protégée ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Seulement si le serveur refuse aussi l’action aux comptes non autorisés. L’interface ne décide pas des droits : une requête peut lui être envoyée autrement.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un compte valide accède à l’objet d’un autre utilisateur
Un défaut d’autorisation peut être exploité avec une session parfaitement valide. L’application reconnaît l’utilisateur, mais ne vérifie pas son droit sur l’objet demandé ou sur l’action choisie. Changer une référence dans une URL, un formulaire ou un appel d’API peut alors donner accès au dossier d’un autre client.
Le contrôle doit combiner le compte connecté, l’organisation à laquelle il appartient, l’objet visé et l’opération. Un droit de lecture n’autorise pas une modification, et un rôle d’administration dans une organisation ne vaut pas pour toutes les autres. Les propriétés modifiables doivent aussi être limitées : accepter tout un objet envoyé par le navigateur peut permettre de changer un propriétaire ou un rôle.
Les écrans ne constituent pas une barrière. Masquer un bouton ne protège pas la route qui réalise l’action. Le serveur doit prendre la décision au moment de l’accès, y compris pour les exports et tâches en arrière-plan.
Les caches méritent la même attention. Une réponse correctement autorisée lors de sa création peut être livrée au mauvais utilisateur si la clé du cache oublie l’identité ou l’organisation. Tester avec plusieurs comptes et organisations permet de vérifier cette séparation dans les deux sens.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Demande objet + action
Client authentifié vers API objets
Trace r20
- Action
Lire les attributs d’autorisation
API objets vers Stockage
- Réponse
Tenant, propriétaire, état
Stockage vers API objets
- Refus / blocage
Refus si la politique échoue
API objets vers Client authentifié
Trace decision=deny
- Action
Export ou accès mis en cache
Client authentifié vers Cache / worker
Trace r22
- Action
Même vérification obligatoire
Cache / worker vers API objets
Trace Version de politique
- Action
Écriture limitée aux propriétés autorisées
API objets vers Stockage
Trace r21
Comment repérer cette attaque
Indices à rechercher
- Un compte ordinaire accède à une fonction réservée.
- Des documents d’un autre utilisateur deviennent visibles.
- Une API accepte une modification que l’interface ne propose pas.
Rechercher les accès à des objets ou les modifications de propriétés hors du périmètre autorisé pour l’acteur. Distinguer les dérogations administratives explicitement accordées.
Éléments à croiser
Pour chaque réponse, confronter l’identité autorisée à l’objet réellement servi. Examiner séparément le chemin sans cache et le chemin avec cache : une clé incomplète peut mélanger deux clients.
Limites de l’interprétation
Une suite de HTTP 403 montre des refus. Elle ne dit rien sur les réponses 200 voisines ni sur une propriété sensible acceptée dans une requête par ailleurs autorisée.
Comment réagir
Corriger le contrôle d’autorisation partagé par les routes concernées et les caches. Retrouver les lectures et modifications avec les identifiants des objets. Réparer les données modifiées avec les responsables métier ; le renouvellement des sessions ne restaure pas leur état antérieur.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Deux comptes de même rôle doivent rester séparés lorsqu’ils appartiennent à des organisations différentes.
- Les permissions de lecture, modification et administration doivent être vérifiées indépendamment.
- Caches, exports et tâches différées doivent conserver le contexte d’autorisation.
À vous de raisonner
L’API vérifie les droits lors de la première requête, mais le cache ne distingue pas les organisations. Quel test révèle le risque restant ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Demandez le même objet avec deux comptes de même rôle appartenant à des organisations différentes, dans les deux ordres. Une réponse autorisée pour le premier ne doit pas être réutilisée pour le second. Le contrôle doit rester effectif sur le chemin complet, pas seulement lors du calcul initial.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
authorization_checked=false- Décision absente sur le chemin avec cache dans le cas fictif ; ce n’est pas un champ standard nginx.
property_allowed- Contrôle au niveau du champ modifié, distinct du droit d’accéder à l’objet entier.
Cas d’accès objet et de mass assignment
JournalJournal synthétique de décisions métier ; la valeur de paid doit être décidée par le processus de paiement.
req=r20 actor=u2 tenant=A object=inv7 owner=u1 action=read decision=deny
req=r21 actor=u2 tenant=A object=inv7 action=update fields=label,paid
req=r21 object_allowed=true property_allowed=false decision=deny
req=r22 actor=u8 tenant=B object=inv7 action=export cache_key=invoice:inv7
req=r22 cache_hit=true authorization_checked=false response=200Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Chercher acteur authentifié, client/organisation, objet, action demandée, propriétaire attendu et décision d’autorisation. Pour un champ modifiable, conserver aussi la décision portant sur cette propriété.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
nginx — journal d’accès HTTP
- Où les trouver
- Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
- Quoi relever
- Comparer route, méthode, statut et horaire des accès au même objet. Vérifier les traces du cache si le frontal en utilise un : elles ne remplacent pas le contrôle d’autorisation du service.
- Accès et prérequis
- Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeStorm-0558
Repères de nommage : Antique Typhoon depuis 2024 chez Microsoft
Des jetons falsifiés donnent accès à des messageries
À partir de mai 2023, des jetons d’authentification falsifiés permettent de consulter les courriels de plusieurs organisations. La confiance dans une signature et sa validation devient ici le point critique du contrôle d’accès.
Ce qu’établit la source. Microsoft attribue l’opération à Storm-0558. Il s’agit de jetons de services cloud, pas de tickets Kerberos : les deux mécanismes ne doivent pas être confondus.
Consulter le rapport Analysis of Storm-0558 techniques for unauthorized email accessMicrosoft · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
Si vous utilisez le service
Si vous voyez le dossier d’un autre client, ne poursuivez pas l’exploration. Signalez au service la référence de votre demande sans diffuser le document reçu.
Pour l’équipe qui exploite le service
- Signalez le défaut sans parcourir les ressources d’autres personnes.
- Faites corriger la règle d’autorisation et ses chemins alternatifs.
- Déterminez les ressources accessibles et les opérations effectivement observées.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- OWASP — Authorization — cheatsheetseries.owasp.org
- OWASP API Security — BOLA — owasp.org
