Broken Access Control

Pourquoi c'est important

L'authentification répond à la question de savoir qui vous êtes. L'autorisation répond à la question de ce que vous avez le droit de faire. Le contrôle d'accès défaillant, c'est ce qui arrive quand une application vérifie la première et oublie la seconde. C'est la faille grave la plus courante sur le web, ce qui explique pourquoi l'OWASP l'a hissée au numéro un du Top 10 2021, et c'est souvent la classe la plus facile à trouver pour un débutant, parce que l'exploitation peut se résumer à changer une seule valeur dans une requête.

Types courants

• IDOR et BOLA : substituez un identifiant d'objet et recevez les données d'un autre utilisateur. Voir IDOR et BOLA.
• Élévation de privilèges verticale : un utilisateur normal atteint des fonctionnalités d'administration auxquelles il ne devrait pas avoir accès. Voir élévation de privilèges.
• Forced browsing : naviguer directement vers des points de terminaison cachés ou non liés qui n'étaient jamais censés être atteignables.
• HTTP method tampering : un verbe sans protection comme HEAD ou OPTIONS contourne un contrôle défini uniquement pour GET et POST.
• Contournement basé sur les en-têtes : usurper X-Forwarded-For: 127.0.0.1 ou utiliser X-Original-URL pour déjouer une restriction d'IP ou de chemin et transformer un 403 en 200.

Un exemple concret

Une requête vers /api/admin/backup renvoie 403 Forbidden avec le message "admin IP required". Ajouter l'en-tête X-Forwarded-For: 127.0.0.1 renvoie 200 OK avec le fichier de sauvegarde, parce que le serveur fait confiance à un en-tête IP fourni par le client qu'il n'a jamais validé. Séparément, changer userId=123 en userId=124 renvoie le profil d'un autre utilisateur parce que le serveur a confirmé que la session était valide mais n'a jamais vérifié la propriété de l'objet. Les deux sont du contrôle d'accès défaillant, trouvés par parameter tampering et manipulation d'en-têtes dans un proxy comme Burp Suite.

Comment le tester

La méthode fiable utilise deux comptes. Connectez-vous en tant qu'utilisateur A, capturez une requête qui atteint l'un de ses objets, puis rejouez-la avec la session de l'utilisateur B, ou substituez simplement l'identifiant, et voyez si les données de l'utilisateur A reviennent. Testez chaque action CRUD, pas seulement les lectures, car la mise à jour et la suppression sont souvent moins protégées. Essayez d'atteindre des points de terminaison d'administration en tant qu'utilisateur normal, d'accéder à l'application sans aucune session, et de combiner les contournements de méthode et d'en-tête ci-dessus. Un contrôle qui tient pour un GET peut échouer pour un DELETE.

Impact

Parce que le contrôle d'accès gouverne chaque objet et chaque action, une seule faille peut exposer les données de tous les utilisateurs, permettre la prise de contrôle de comptes ou accorder le contrôle administratif. Les incidents réels vont de la lecture des factures d'autres clients à l'extraction massive de données via un seul identifiant énumérable, ce qui explique pourquoi les équipes de triage classent systématiquement ces trouvailles au plus haut.

Prévention

Refusez par défaut et accordez explicitement. Imposez l'autorisation côté serveur sur chaque requête, vérifiez la propriété de l'objet plutôt que le seul état de connexion, appliquez les contrôles à toutes les méthodes, et ne faites jamais confiance aux en-têtes fournis par le client pour l'identité ni aux URL cachées pour la protection. Centralisez la logique, testez avec plusieurs comptes, et alertez sur les accès qui franchissent les frontières entre utilisateurs.