Contrôle d'accès¶
Le contrôle d'accès définit qui — ou quoi — est autorisé à effectuer une action ou à accéder à une ressource. Il repose sur trois piliers complémentaires qu'il importe de ne pas confondre : l'authentification confirme que l'utilisateur est bien celui qu'il prétend être ; la gestion de session identifie les requêtes provenant d'un même utilisateur authentifié ; le contrôle d'accès proprement dit détermine si cet utilisateur est autorisé à effectuer l'action qu'il tente.
Une vulnérabilité de contrôle d'accès apparaît lorsque l'application ne vérifie pas correctement les permissions associées à une action ou à une ressource. Ces failles découlent presque toujours d'une hypothèse erronée du développeur sur ce qu'un utilisateur est censé pouvoir faire. Elles sont souvent simples à exploiter, mais critiques : accès à des fonctions d'administration, modification de données sensibles, élévation de privilèges, voire compromission complète.
Ressources cachées mais non protégées¶
Le cas le plus simple : deviner l'URL d'un panneau d'administration ou d'une ressource sensible. Si l'application ne vérifie pas les permissions, quiconque connaît l'URL y accède. Ces emplacements transparaissent souvent dans le code source HTML, les fichiers JavaScript, les commentaires ou des endpoints d'API non documentés. C'est ce qu'on appelle parfois une sécurité « par l'obscurité » — illusoire dès que l'adresse est connue.
Privilèges stockés côté client¶
Certaines applications stockent les privilèges dans un cookie ou un paramètre côté client, sans vérification serveur. Modifier la valeur — par exemple un attribut de rôle dans un cookie ou le stockage local — suffit alors à escalader ses privilèges. De même, certaines fonctionnalités s'appuient sur des échanges JSON insuffisamment contrôlés, dans lesquels on peut tenter d'injecter un rôle ou un privilège non autorisé.
Contournement via en-têtes de réécriture d'URL¶
Certaines applications restreignent l'accès par des règles du type « refuser POST sur /admin/deleteUser aux non-managers ». Mais des en-têtes comme X-Original-URL et X-Rewrite-URL, pris en charge par certains frameworks, permettent de réécrire l'URL effectivement traitée par le serveur. On présente alors une URL anodine dans la ligne de requête et l'URL restreinte dans l'en-tête :
Point important : les paramètres de requête (?username=...) doivent rester dans l'URL de base, tandis que seul le chemin restreint figure dans l'en-tête :
Contournement par changement de méthode HTTP¶
Quand une application autorise une méthode (GET) mais en bloque une autre (POST) pour les utilisateurs non privilégiés, il suffit parfois de changer la méthode de la requête pour contourner la restriction. Burp propose une fonction « Change request method » qui automatise ce test.
Contrôles d'URL trop permissifs¶
Des variantes d'une même URL peuvent être traitées comme des endpoints distincts alors qu'elles mènent à la même ressource. Si le contrôle d'accès ne normalise pas l'URL avant de l'évaluer, l'une de ces formes peut passer là où l'originale est bloquée :
Workflows multi-étapes mal sécurisés¶
Certaines actions se déroulent en plusieurs étapes (par exemple une confirmation). Une erreur fréquente consiste à sécuriser la première étape mais pas la dernière, en supposant qu'un utilisateur non autorisé ne pourra jamais l'atteindre. Il suffit alors de construire directement la requête finale pour contourner toute la chaîne de vérification.
Contrôle fondé sur l'en-tête Referer¶
Certaines applications n'autorisent l'accès qu'en vérifiant la présence d'un en-tête Referer pointant vers une zone protégée. Comme cet en-tête est entièrement contrôlable par le client, il suffit de l'ajouter à la requête pour accéder à la fonctionnalité :
GET /admin-roles?username=victime&action=upgrade HTTP/1.1
Host: site-vulnerable.example
Referer: https://site-vulnerable.example/admin
Cookie: session=...
Contrôle fondé sur la géolocalisation¶
Certains services (banques, plateformes de média) restreignent l'accès selon la position géographique. Cette restriction se contourne par un proxy, un VPN ou une manipulation de la géolocalisation côté client — un contrôle de localisation ne devrait jamais être la seule barrière protégeant une ressource sensible.
Synthèse¶
Les vulnérabilités de contrôle d'accès apparaissent chaque fois que l'application fait confiance au client, ne normalise pas ses URL, laisse une étape de workflow non protégée, s'appuie sur des en-têtes manipulables, applique ses règles uniquement côté front, ou — la cause racine — ne vérifie pas systématiquement les permissions côté serveur. La règle défensive tient en une phrase : toute décision d'autorisation doit être prise sur le serveur, à chaque requête, sans jamais se fier à une information fournie par le client.
Aide-mémoire¶
| Faille | Approche |
|---|---|
| Ressource cachée | Deviner l'URL ; chercher dans HTML, JS, commentaires |
| Privilège côté client | Modifier cookie, stockage local ou champ JSON de rôle |
| Règle sur le chemin | En-têtes X-Original-URL / X-Rewrite-URL |
| Méthode restreinte | Changer la méthode HTTP de la requête |
| URL non normalisée | Variantes de casse, suffixes, barre oblique finale |
| Workflow multi-étapes | Émettre directement la requête de l'étape finale |
Contrôle par Referer |
Ajouter l'en-tête attendu |
| Restriction géographique | Proxy, VPN, manipulation de la géolocalisation |