Pentest en boîte grise : quels accès fournir, et pourquoi

En boîte grise, le pentester reçoit une partie de ce que connaît un utilisateur légitime : des comptes de test, souvent la documentation de l’API, parfois un schéma d’architecture. Il n’a pas le code source. C’est l’approche intermédiaire entre la boîte noire et la boîte blanche, et c’est celle que nous appliquons par défaut sur les audits d’applications web.

La raison tient en une phrase : la plupart des failles graves d’une application métier se trouvent derrière la page de connexion.

Ce que vous fournissez

Tout dépend du périmètre.

Pour une application web ou une API, l’idéal est un compte par rôle (utilisateur, manager, administrateur…) et, si votre plateforme sert plusieurs clients, deux organisations distinctes avec chacune leurs comptes. Ajoutez la documentation de l’API si elle existe, un fichier OpenAPI ou une collection Postman suffit, et un environnement de préproduction rempli de données fictives. Tester en production reste possible, avec des règles écrites à l’avance.

Pour un réseau interne et un Active Directory, le point de départ est un compte utilisateur standard du domaine et un poste, sur site ou par accès distant. C’est le scénario d’un salarié dont le mot de passe a été volé par hameçonnage, ou d’un poste infecté par une pièce jointe.

Pour un environnement cloud, un compte en lecture seule permet de passer la configuration en revue, et un compte utilisateur standard sert aux tests ciblés.

Dans tous les cas, ces accès sont créés pour l’audit et désactivés juste après.

Pourquoi c’est souvent le meilleur rapport entre profondeur et budget

Le temps d’un pentest est compté en jours. En boîte noire, une bonne partie part à chercher comment entrer. En boîte grise, on entre directement, et ce temps sert à tester ce que l’application fait de vos données.

Or c’est là que se trouve le gros des risques. Le contrôle d’accès défaillant est premier du Top 10 de l’OWASP pour les applications web, et dans l’API Security Top 10, trois des cinq premières catégories concernent l’autorisation. Aucune de ces failles ne se teste correctement sans comptes.

Ce qu’on teste avec deux comptes

Prenons un exemple simple. Une plateforme de facturation, deux entreprises clientes, A et B. Le pentester est connecté avec un compte de A.

Il télécharge une facture de A et regarde la requête : /api/invoices/18342. Il remplace le numéro par celui d’une facture de B. Si le serveur la renvoie, c’est une faille de contrôle d’accès horizontal, appelée IDOR ou BOLA selon les écoles. Elle est banale, et elle est grave : n’importe quel client peut lire les données de tous les autres. Un scanner automatique ne la voit pas, parce que la réponse est parfaitement valide du point de vue technique.

Avec plusieurs rôles, le pentester teste aussi l’accès vertical : un simple utilisateur peut-il appeler une fonction d’administration en connaissant son adresse ? Et l’accès aux propriétés d’un objet : si l’on ajoute "role": "admin" dans la requête qui met à jour son propre profil, est-ce que le serveur l’accepte ? Ce dernier cas, l’affectation de masse, arrive plus souvent qu’on ne le croit sur les frameworks qui lient automatiquement les champs reçus aux objets en base.

Enfin, la logique métier : appliquer deux fois le même code promotionnel, valider une commande sans passer par l’étape de paiement, inviter un utilisateur dans une organisation qui n’est pas la sienne. Ces tests demandent de comprendre l’application, et donc de pouvoir l’utiliser.

« Ce n’est pas réaliste, un attaquant n’aurait pas de compte »

C’est l’objection la plus fréquente, et elle ne tient pas longtemps. Sur un SaaS, n’importe qui peut en général s’inscrire, ou devenir client. Sur un réseau interne, un compte volé par hameçonnage est le point de départ le plus courant des attaques par ransomware. Les identifiants de vos salariés circulent peut-être déjà dans des fuites de données.

La boîte grise répond à une question plus utile que « peut-on entrer ? » : une fois qu’un attaquant a un pied dans la porte, jusqu’où peut-il aller ? Dans un Active Directory, c’est précisément ce que l’audit mesure : quels chemins mènent d’un simple compte utilisateur aux droits d’administration.

Ses limites

Sans le code, certaines failles restent invisibles ou très difficiles à prouver : un paramètre caché que l’interface n’envoie jamais, un jeton de réinitialisation de mot de passe généré de façon prévisible, un secret écrit en dur dans le code, une condition de concurrence qui ne se déclenche qu’une fois sur mille. C’est le terrain de la boîte blanche.

La boîte grise ne remplace pas non plus un regard sur votre surface externe. Une application impeccable hébergée à côté d’un serveur oublié reste une entreprise exposée.

Préparer un audit en boîte grise

Quelques points font gagner du temps à tout le monde :

• créer les comptes de test quelques jours avant le début, et vérifier qu’ils fonctionnent ;
• remplir la préproduction avec des données fictives réalistes (une facture vide ne permet pas de tester grand-chose) ;
• prévenir les équipes qui surveillent les alertes, pour qu’elles ne bloquent pas l’audit en pensant à une attaque ;
• décider à l’avance si le pare-feu applicatif reste actif pendant les tests ou si les adresses du pentester sont autorisées. Les deux choix se défendent, mais ils ne mesurent pas la même chose.

Nos pentests d’application web et nos audits Active Directory suivent cette approche. Le formulaire de devis la propose par défaut, et l’article Audit d’intrusion (pentest), approches et méthodologie replace la boîte grise parmi les autres approches.