Authentification et permissions, qui peut vraiment faire quoi.
Le contrôle d'accès est la première catégorie de failles du classement OWASP, et de loin la plus fréquente dans ce que je trouve. Sa particularité : la requête qui l'exploite est parfaitement normale. Rien ne dépasse, aucun caractère suspect, aucune alerte. Simplement un compte qui obtient quelque chose que personne n'avait prévu de lui donner.
La faille qui ne ressemble pas à une attaque.
Une injection SQL se voit : une apostrophe inattendue, une syntaxe hors norme, un journal qui remonte l'anomalie. Une faille de contrôle d'accès, non. L'attaquant se connecte avec son vrai compte, appelle une adresse légitime, et remplace un numéro par un autre. Du point de vue du serveur, tout est en ordre.
C'est pour cette raison qu'elle survit aux outils, aux pare-feux applicatifs et souvent aux revues de code. Le code fait exactement ce qu'on lui a demandé : il retourne la fiche numéro 8340. Ce qui manque, c'est la ligne qui vérifie que la fiche 8340 appartient bien à la personne qui le demande. Cette ligne, on l'oublie surtout aux endroits ajoutés après coup, dans l'urgence, sur une fonctionnalité qui devait être temporaire.
Le risque grandit avec le succès du produit. Une application démarre avec deux rôles et une poignée d'écrans. Trois ans plus tard elle en a sept, plus des exceptions, plus une API mobile qui refait ses propres vérifications, plus un back-office interne. Personne ne détient plus la matrice complète, et c'est exactement dans ses trous que se logent les problèmes.
Ce que je franchis.
Chaque ligne ci-dessous correspond à une frontière que votre application est censée tenir. Mon travail consiste à essayer de passer, méthodiquement.
- Accès horizontal (IDOR, BOLA) : atteindre les données d'un autre compte du même niveau en changeant un identifiant, un jeton de partage ou un numéro de document.
- Élévation verticale : obtenir depuis un compte standard une action réservée à un administrateur, en appelant directement la fonction que l'interface se contente de masquer.
- Cloisonnement multi-organisations : franchir la frontière entre deux clients d'une même plateforme, le défaut le plus coûteux d'un produit SaaS.
- Divergence interface et API : une règle appliquée dans l'écran mais absente de l'appel qui se trouve derrière, ou présente sur la version web et oubliée sur la version mobile.
- Cycle de vie des sessions : expiration réelle, invalidation à la déconnexion et au changement de mot de passe, sessions parallèles, jetons qui survivent à la révocation.
- Jetons et signatures : algorithme accepté, vérification de la signature, champs de rôle modifiables côté client, durée de validité et rafraîchissement.
- Reprise de compte : mot de passe oublié, changement d'adresse de courriel, liens d'invitation, codes à usage unique rejouables ou devinables.
- Second facteur : contournement par une route qui l'ignore, par un flux d'inscription alternatif, ou par un jeton émis avant sa validation.
Comment se passe une mission.
Reconstitution du modèle de droits
On écrit ensemble ce que chaque rôle est censé pouvoir faire. Beaucoup de clients découvrent à cette étape que le document n'existe nulle part, ou qu'il ne correspond plus à l'application. C'est déjà un résultat : on ne peut pas défendre une frontière qu'on n'a pas tracée.
Comptes et jeux de données
Je crée ou vous me fournissez les comptes nécessaires, avec des données propres à chacun : documents, commandes, messages. Sans données distinctes, impossible de prouver qu'une frontière a été franchie.
Inventaire des actions sensibles
Je parcours l'application avec le compte le plus privilégié et j'enregistre chaque action qui lit ou modifie quelque chose d'important. Cet inventaire devient la liste des cas à rejouer.
Franchissement systématique
Chaque action est rejouée avec chaque rôle, puis avec les identifiants appartenant à un autre compte, puis à une autre organisation. C'est répétitif, c'est long, et c'est précisément ce qu'aucun outil ne sait faire à votre place.
Chaînage
Un accès isolé vaut peu, un enchaînement vaut cher. Je vérifie ce qu'on peut atteindre en partant d'une seule brèche : un identifiant récupéré ici ouvre-t-il une fonction là-bas, et jusqu'où descend la chaîne.
Rapport et retest
Vous recevez la matrice avec ce qui tient et ce qui cède, chaque franchissement avec sa requête et sa preuve, et le correctif attendu. Après vos corrections, je rejoue l'ensemble des cas concernés.
Ce que ça donne en pratique.
Failles réelles, trouvées, signalées et corrigées. Les clients et les périmètres ne sont jamais divulgués.
Questions fréquentes.
En quoi est-ce différent d'un test d'intrusion classique ?
Un test d'intrusion couvre large : injections, configuration, exposition, permissions. Cette mission ne traite qu'un seul axe, mais en profondeur. Là où un test généraliste vérifie quelques accès emblématiques, ici je construis la matrice complète et je la franchis case par case. C'est le bon choix quand votre application a beaucoup de rôles ou plusieurs organisations clientes.
Combien de comptes de test faut-il prévoir ?
Au minimum deux comptes de même niveau, sans quoi l'accès horizontal est intestable : il faut pouvoir tenter d'atteindre les données de l'un depuis l'autre. Ensuite un compte par niveau de privilège, et si vous êtes en multi-organisations, deux organisations distinctes avec des données à elles.
Vous testez sur la production ou sur un environnement dédié ?
Un environnement de recette proche de la production est idéal, parce qu'il autorise des manipulations qu'on s'interdit ailleurs. Sur la production, je travaille uniquement avec des comptes et des données créés pour l'audit, et je ne fais rien de destructif. Les deux fonctionnent, l'essentiel est de le décider avant.
Pourquoi les scanners ne trouvent-ils jamais ces failles ?
Parce qu'un outil ne connaît pas votre modèle de droits. Quand il envoie une requête et reçoit un code 200 avec des données, il conclut que tout va bien : rien dans la réponse ne lui dit que ce compte n'aurait pas dû les voir. Cette information n'existe que dans votre tête et dans vos spécifications.
On a du SSO et du MFA, est-ce que ça ne règle pas la question ?
Cela règle l'authentification, c'est-à-dire la preuve que vous êtes bien vous. Cela ne dit rien de l'autorisation, c'est-à-dire ce que vous avez le droit de faire une fois entré. La majorité des failles que je trouve ici touchent des utilisateurs parfaitement authentifiés, souvent avec un second facteur.
Les autres prestations.
Test d'intrusion web
Si vous voulez une couverture large plutôt qu'un axe unique, le test d'intrusion web inclut les permissions parmi d'autres familles de failles.
DécouvrirAudit de sécurité d'API
Quand l'application expose une API, les mêmes frontières doivent être vérifiées côté endpoints, où l'interface ne masque plus rien.
DécouvrirFaites auditer vos contrôles d'accès.
Dites-moi combien de rôles distincts existent dans votre application, si plusieurs organisations clientes cohabitent, et si une API mobile refait ses propres contrôles. Je vous réponds avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.