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
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 laisse une personne consulter une ressource ou effectuer une action sans en avoir le droit. Vérifier son identité à la connexion ne suffit pas. Le site doit aussi contrôler ses droits pour chaque document, fonction d’administration ou champ sensible qu’elle veut utiliser.
- 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
Sur le serveur, vérifiez les droits pour chaque ressource et chaque action. Testez avec des comptes de même rôle et d’organisations différentes, en vérifiant aussi les réponses des caches.
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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Il faut aussi que le serveur refuse l’action aux comptes qui n’en ont pas le droit. Masquer le bouton ne suffit pas, car la même requête peut arriver sans passer par cet écran.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un compte valide accède à l’objet d’un autre utilisateur
L’utilisateur est bien connecté, mais le service ne vérifie pas ses droits sur le document ou l’action demandée. En changeant une référence dans une URL, un formulaire ou un appel d’API, il peut alors atteindre le dossier d’un autre client. Une session valide ne protège donc pas, à elle seule, contre un défaut d’autorisation.
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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeStorm-0558
Noms et appellations : Antique Typhoon depuis 2024 chez Microsoft
Des jetons falsifiés donnent accès à des messageries
À partir de mai 2023, des attaquants utilisent des jetons d’authentification falsifiés pour lire les courriels de plusieurs organisations. Le contrôle d’accès est trompé au niveau de la signature et de sa validation.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
