IDOR et BOLA

Pourquoi c'est Important

IDOR et BOLA representent la classe de vulnerabilite API la plus impactante. Broken Object Level Authorization occupe la premiere position du OWASP API Security Top 10 depuis sa creation en 2019 et a conserve cette position dans la mise a jour de 2023.

La raison est simple : les API exposent des identifiants d'objets dans les URL, les corps de requete et les parametres de requete. Si le serveur ne verifie pas que l'utilisateur demandeur possede ou a la permission d'acceder a l'objet reference, tout utilisateur authentifie peut acceder aux donnees de n'importe quel autre utilisateur en manipulant ces identifiants.

Les vulnerabilites BOLA reelles ont expose des millions d'enregistrements utilisateurs sur des plateformes allant des services financiers aux reseaux sociaux. La vulnerabilite est particulierement dangereuse car :

• Elle ne necessite aucun outil ou competence particuliere pour etre exploitee
• Une seule vulnerabilite peut exposer les donnees de chaque utilisateur
• Elle contourne souvent le chiffrement puisque l'attaquant est authentifie
• L'exploitation automatisee peut collecter des bases de donnees entieres

Pour les testeurs de penetration et les chasseurs de bug bounty, le test BOLA/IDOR est l'une des premieres competences a maitriser car il produit le plus grand nombre de constatations valides par rapport a l'effort investi.

Comment Fonctionnent IDOR et BOLA

Le Schema de Base

Une application attribue des identifiants aux objets : profils utilisateurs, commandes, factures, fichiers, messages ou toute autre ressource. Lorsqu'un utilisateur demande un objet, l'API recoit l'identifiant et retourne les donnees correspondantes. La vulnerabilite existe quand l'API verifie l'authentification (cet utilisateur est-il connecte ?) mais ne verifie pas l'autorisation (cet utilisateur a-t-il la permission d'acceder a cet objet specifique ?).

Types d'Identifiants Courants

• ID numeriques sequentiels : /api/users/1001 a /api/users/9999. Faciles a enumerer.
• UUID : /api/orders/a3f8e2c1-.... Plus difficiles a deviner mais pas impossibles s'ils sont divulgues dans d'autres reponses.
• Valeurs encodees : identifiants en Base64 ou haches qui peuvent parfois etre decodes ou predits.
• Cles composites : /api/org/5/user/12. Plusieurs identifiants qui necessitent chacun des verifications d'autorisation.

Methodologie de Test

1. Creer deux comptes avec des roles ou des droits de propriete differents
2. Capturer toutes les requetes API contenant des identifiants d'objets
3. Echanger les identifiants entre les comptes
4. Tester avec toutes les methodes HTTP (GET pour la lecture, PUT/PATCH pour la mise a jour, DELETE pour la suppression)
5. Verifier a la fois le code de statut de la reponse et le corps de la reponse

Prevention

La correction necessite des verifications d'autorisation cote serveur sur chaque requete qui accede a une ressource specifique a un utilisateur. Le serveur doit verifier que l'utilisateur authentifie a la permission d'acceder a l'objet specifique reference dans la requete, et pas seulement qu'un jeton d'authentification valide est present.

• Implementer des verifications de permissions au niveau objet dans le middleware API ou dans la couche d'acces aux donnees
• Ne jamais compter sur l'obscurite (UUID) comme substitut a l'autorisation
• Utiliser des references indirectes lorsque possible (mapper des jetons specifiques a la session vers les ID reels de base de donnees cote serveur)
• Journaliser tous les patterns d'acces et alerter sur les acces horizontaux entre les limites utilisateurs