Le contrôle d'accès, c'est l'ensemble des mécanismes qui détermine qui peut voir ou utiliser quoi dans une application. On parle de défaillance dès lors que des personnes parviennent à accéder à des ressources qui sont censées lui être interdites, que ce soit des informations ou des fonctionnalités.
Cette catégorie A01 :2021 englobe les faiblesses pouvant mener à de telles défaillances.
Découvrez un cas d’attaque
En 2014, Snapchat a été victime d'une attaque par force brute, mettant en lumière des vulnérabilités critiques dans ses systèmes de sécurité. Cette attaque a abouti à la divulgation des données de 4,6 millions d'utilisateurs ; notamment des numéros de téléphone. Cela a suscité une vive inquiétude quant à la sécurité des données sur les plateformes de réseaux sociaux.
En exploitant cette faille, les attaquants pouvaient automatiser le processus de recherche et de collecte des informations de compte.
Snapchat a initialement minimisé le problème jusqu’à la publication d’une archive complète sur le site snapachatdb.info contenant les noms d'utilisateur et les numéros de téléphone de 4,6 millions d'utilisateurs.
Cet incident a souligné l'importance d'une authentification et d'une gestion des sessions robustes dans les applications web, car les vulnérabilités résultantes peuvent permettre aux attaquants d'accéder à des comptes et/ou à des données non autorisées.
Identifiez les attaques contre le contrôle d'accès
Plusieurs types d'attaques peuvent compromettre ces mécanismes de défense. Nous allons explorer ici trois types d'attaques spécifiques :
L’attaque par découverte d'URL ;
Les références directes d'objets non sécurisés (ou IDOR, pour Insecure Direct Object Reference) ;
L’attaque CSRF (Cross-Site Request Forgery).
L’attaque par découverte d’URL
Lorsqu'on aborde la problématique de l'attaque par découverte d'URL, il est essentiel de comprendre comment un design apparemment anodin peut ouvrir la porte à des menaces de sécurité. Prenons un exemple concret pour illustrer cette idée.
Imaginez une application web qui distingue deux catégories d'utilisateurs : les « Employés » et les « Clients », chacun ayant des droits d'accès spécifiques à certaines parties de l'application.
Lorsqu'un client se connecte à l'application, il est dirigé vers une page principale dont l'URL est la suivante, pour y saisir ses identifiants et mot de passe : https://example.com/client_login.html . Cette URL révèle une structure définie où client_login.html est désigné comme la page de connexion pour les clients. Cependant, cette apparence inoffensive cache un risque potentiel.
En effet, un attaquant pourrait intuitivement essayer d'accéder à la page de connexion des employés en modifiant légèrement l'URL, peut-être en essayant quelque chose comme employee_login.html . Dans cet exemple, il restera encore à saisir des identifiants et mots de passe valides, mais c’est déjà une étape de moins pour l’attaquant.
Cet exemple met en lumière un problème de sécurité : la prévisibilité et la transparence des URL peuvent servir d'indices aux personnes malveillantes.
Mais alors, est-ce que cela signifie qu'un attaquant peut découvrir toutes les pages de mon application, même celles qui ne sont pas explicitement référencées ?
Effectivement, les attaquants peuvent utiliser des outils automatisés pour scanner et découvrir les URL possibles de votre application, y compris les pages d'administration commeadminou mon_compte . Il est donc crucial de garder à l'esprit que toute page peut potentiellement être trouvée et accédée, même sans lien direct depuis le site.
L’attaque par références directes d’objets non sécurisées
Imaginez-vous en tant qu'utilisateur naviguant sur une application web. Vous accédez à votre compte et, naturellement, vous arrivez sur une page principale. C'est là que les choses deviennent intéressantes. Prenez un moment pour observer l'URL :
https://example.com/index.php/view?account=13
Vous remarquerez que le paramètre account"13" semble être un identifiant unique, probablement lié à votre compte spécifique dans la base de données de l'application.
Que se passe-t-il si on remplace cette valeur “account=13” par “account=1” ?
Un attaquant va se poser exactement la même question.
Pour tester, ce dernier va simplement manipuler la requête comme dans cet exemple :
https://example.com/index.php/view?account=1
Si la seule saisie de l’URL suffit à accéder à la page (comme dans l’exemple ci-dessus), c'est ce qu'on appelle une référence d'objet non sécurisée, ou IDOR (Insecure Direct Object Reference).
L’attaque CSRF (Cross-Site Request Forgery)
L’objet de l’attaque CSRF (ou injections de requêtes illégitimes par rebond) est de transmettre à un utilisateur authentifié une requête HTTP falsifiée qui pointe sur une action interne au site, afin qu'il l'exécute sans en avoir conscience et en utilisant ses propres droits.
Ces attaques sont possibles car les navigateurs envoient automatiquement certains types de jetons d'authentification à chaque requête adressée à un site Web. L’attaque profite donc de la session préalablement authentifiée de l’utilisateur avec l’application en question.
Mais concrètement, comment peut se dérouler une attaque CSRF contre un utilisateur de mon application web ?
Vous êtes l’administrateur du site www.openclassrooms.mybank.com
1. Marie se connecte à son compte sur le site www.openclassrooms.mymank.com, pour vérifier ses dernières transactions. Le processus d'authentification est sécurisé, et un cookie d'authentification est stocké dans son navigateur.
2. Plus tard, en naviguant sur Internet, Marie tombe sur un site web proposant de participer à un jeu-concours pour gagner un smartphone. Ce site, à l'apparence innocente, est en réalité contrôlé par un attaquant.
3. Sur ce site, un formulaire HTML est discrètement intégré dans une page. Ce formulaire est configuré pour envoyer une requête à www.openclassrooms.mybank.com, avec une action précise : transférer de l'argent du compte de Marie vers un compte contrôlé par l'attaquant. Le formulaire pourrait ressembler à ceci, bien qu'il soit caché à la vue de Marie :
<form action="https://www.mybank.com/transfer" method="POST" style="display:none;">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="toAccount" value="Compte-Attaquant">
<input type="submit" value="Gagnez votre nouvel iphone!">
</form>4. Lorsque le formulaire est soumis, le navigateur de Marie envoie la requête à www.openclassrooms.mybank.com, y compris le cookie d'authentification valide. La banque traite la requête comme légitime puisqu'elle provient d'une session authentifiée, réalisant ainsi le transfert d'argent sans que Marie en ait conscience.
Comment puis-je me protéger de ces différents types d’attaques ?
Plusieurs mécanismes existent pour se protéger des attaques contre les contrôles d’accès défaillants, nous allons voir cela en détail dans la prochaine section !
Protégez-vous des attaques contre le contrôle d'accès
Découvrons comment protéger votre application web de ces différents types d’attaques.
Pour se protéger contre une attaque par découverte d’URL, plusieurs actions techniques peuvent être mises en œuvre, en particulier dans le cadre d'un serveur Apache.
Restriction d'accès aux répertoires sensibles :
Configuration Apache : Utiliser des directives dans le fichier .htaccess ou dans le fichier de configuration principal (httpd.conf) pour restreindre l'accès.
Exemple :
<Directory"/var/www/html/admin">
Requirealldenied
</Directory>Désactivation de l'affichage de l'index des répertoires :
Configuration Apache : Empêcher Apache de lister le contenu des répertoires si aucun fichier index n'est présent.
Exemple :
<Directory "/var/www/html"> Options -Indexes </Directory>
</pre>
Pour renforcer la sécurité contre les attaques par références directes d'objets non sécurisées (IDOR), une recommandation technique efficace consiste à utiliser des références indirectes pour les ressources accessibles par les utilisateurs.
Cela signifie que chaque utilisateur voit des URL et des paramètres uniques qui ne sont valides que durant sa session. Par exemple, une URL telle que https://www.example.com/mes-factures/36 pourrait en interne correspondre à un identifiant complexe et aléatoire, comme ffc61035-b579-44e0-b7fc-199bb005cade . Cette méthode empêche l'accès non autorisé à des données sensibles, car même si deux utilisateurs consultent la même URL symbolique, les ressources réellement accédées dépendent de leur session et de leurs droits d'accès.
Mon application est développée en PHP, comment mettre en place ce mécanisme ?
L’utilisation d’un framework PHP comme Laravel permet l’utilisation d’Eloquent ORM qui aide à la manipulation de la base de données de manière sécurisée.
Vous pouvez par exemple mettre en place un système d’UUIDs (Universal Unique Identifier) en implémentant Eloquent ORM.
Parmi les vulnérabilités détaillées dans ce chapitre, il nous reste à aborder l’attaque Cross Site Request Forgery.
Le principe est le suivant : garantir que les actions sensibles ne sont pas réalisées via des URLs entièrement prédictibles, en ajoutant un token dont la valeur change à chaque utilisation. Si aucun token n’est émis ou que la valeur reçue par le serveur est différente de celle qu’il attendait, alors la requête est refusée.
De nombreux frameworks de développement possèdent désormais des protections intégrées par défaut contre les attaques CSRF.
Par exemple, si vous utilisez Laravel comme framework PHP, il intègre par défaut le middleware “verifycsrftoken” qui se charge de vérifier la présence d’un token CSRF unique.
Je n’utilise pas de framework, comment faire ?
Si votre framework ne dispose pas d'une protection intégrée contre les CSRF ou si vous n’utilisez pas de framework, il est crucial d'ajouter manuellement des tokens CSRF à toutes les requêtes modifiant l'état de l'application (celles qui entraînent des actions sur le site) et de les valider côté serveur. Cette mesure garantit que chaque action entreprise sur le site provient bien de l'utilisateur authentifié, empêchant ainsi les attaques par falsification.
Ces protections doivent être complétées par des recommandations généralistes pour renforcer le contrôle d'accès, en nous appuyant sur les directives du Top 10 OWASP :
Principes de moindre privilège : Assurez-vous que les utilisateurs n'ont que le niveau d'accès strictement nécessaire à leurs fonctions. Limitez l'accès aux ressources sensibles et ne l'accordez que lorsque cela est absolument nécessaire.
Vérifications d'accès côté serveur : Toutes les demandes d'accès aux ressources et fonctionnalités sensibles doivent être vérifiées côté serveur. Ne comptez jamais uniquement sur les contrôles côté client, car ils peuvent être facilement contournés.
En résumé
La catégorie A01:2021 correspond aux contrôles d’accès défaillants
Une vulnérabilité de cette catégorie sur l’application Snapchat en 2014 a mené à la fuite de données de 4,6 millions d’utilisateurs, dont leur numéro de téléphone.
Les attaques comme la découverte d'URL, les références directes d'objets non sécurisées (IDOR), et la CSRF démontrent différentes failles dans les systèmes de contrôle d'accès.
L’utilisation de framework de développement permet l’implémentation de systèmes de sécurité pour améliorer les contrôles d’accès.
Les cheatsheet sur la sécurité d'un service web, concernant la vulnérabilité IDOR, concernant la vulnérabilité CSRF et concernant la sécurité du mécanisme d'autorisation partagent des astuces utiles pour éviter la défaillance des contrôles d’accès.
Maintenant que nous avons compris comment renforcer les contrôles d'accès pour empêcher les intrusions, passons au chapitre suivant pour explorer comment sécuriser les données sensibles à travers la cryptographie.
