Internet n’est PAS un endroit sûr. Merveilleux en soi, certes, et utile de bien des façons. Mais le cyberespace regorge également d’acteurs malveillants : voleurs, hackers et autres criminels cherchant à s’attaquer aux plus vulnérables. Ne vous alarmez pas tout de suite. Tant que vous savez à quoi vous avez affaire, vous avez toutes les chances de résister aux intrus. Et, en 2022, il y a fort à parier que vous ferez face à des menaces de contrôle d’accès défaillant (BAC).
En effet, détrônant les injections SQL, le BAC a pris la tête du classement OWASP des 10 principaux risques de sécurité des applications web. Oui, selon la plus grande fondation non lucrative dédiée à la sécurité logicielle, 3,81 % des applications testées étaient vulnérables aux menaces de contrôle d’accès défaillant (ce qui représente BEAUCOUP, soit dit en passant).
Mais prenons quelques pas de recul. Qu’est-ce que le contrôle d’accès ? Et, par conséquent, qu’est-ce que le contrôle d’accès défaillant ? Comment « défaille »-t-il exactement, et y êtes-vous vulnérable ? Toutes de bonnes questions, alors plongeons-y.
Contrôle d’accès défaillant : explications et exemples
Comme vous pouvez le deviner à partir du nom, le contrôle d’accès défaillant est une menace de sécurité par laquelle des intrus parviennent à accéder à des données non autorisées. Le contrôle d’accès, quant à lui, recouvre les politiques et mécanismes garantissant que des utilisateurs spécifiques n’ont accès qu’à des composants spécifiques.
Pour faire simple, examinez n’importe quel système : il comporte différentes personnes jouant différents rôles. Vous souhaitez qu’elles puissent le faire librement (dans une certaine mesure), mais vous voulez rarement que toutes les personnes impliquées puissent accéder à l’ensemble du système. C’est là qu’intervient le contrôle d’accès.
Bien entendu, lorsqu’il est défaillant et que n’importe qui peut accéder à ce qu’il veut, c’est le chaos. En contournant les autorisations prévues, les intrus peuvent divulguer des informations sensibles, modifier et supprimer définitivement toutes les données, ou exécuter des fonctions métier que vous ne souhaiteriez pas leur voir accomplir.
Et, le contrôle d’accès défaillant étant aujourd’hui la principale menace de sécurité des applications web dans le monde, nous avons observé d’innombrables exemples de BAC réussis. Des petites entreprises victimes en raison de leur dépendance à des données non vérifiées jusqu’aux plus grands empires en ligne dévalisés par des hackers naviguant de force vers des URL cibles.
Avant d’examiner des exemples spécifiques, cependant, nous allons déterminer ce qu’est le contrôle d’accès dans le monde du logiciel et ce qui le fragilise.
Qu’est-ce que le contrôle d’accès défaillant ?
Le contrôle d’accès défaillant est un manquement de l’application web à appliquer et maintenir des politiques d’accès préétablies. Quelles sont ces politiques ? Du point de vue des applications web, le contrôle d’accès se divise en trois grandes catégories :
- Contrôle d’accès administratif. Dans ce cas, nous parlons des protocoles d’accès définis et mis en place pour appliquer la politique de sécurité générale. En général, ce type se divise en deux sous-catégories : les protocoles liés au personnel et les protocoles métier. Pour vous donner quelques exemples plus concrets, il s’agirait notamment des politiques quotidiennes, des procédures de recrutement et des vérifications des antécédents.
- Contrôle d’accès technique. À l’opposé, également connu sous le nom de contrôle d’accès logique, se trouvent les restrictions basées sur les logiciels et le matériel. Celles-ci créent plusieurs couches de protection supplémentaires pour protéger le système (ou ses ressources) contre les accès non autorisés. Ces mises en œuvre incluent généralement des éléments tels que des mots de passe, des cartes à puce, différentes clés numériques, des protocoles, des pare-feux, et bien plus encore. Comme vous pouvez vous y attendre, elles contribuent considérablement à renforcer la sécurité des API du système.
- Contrôle d’accès physique. Cette partie couvre les caméras de surveillance, les portails, les clôtures, les agents de sécurité et les serrures qui limitent l’accès à des environnements spécifiques. Comme son nom l’indique, le contrôle d’accès physique se concentre sur l’aspect non technologique de l’équation. Il va sans dire que cette catégorie est tout aussi importante que les deux précédentes, mais nous aborderons avant tout la perspective « technique » aujourd’hui.
Comment le contrôle d’accès est mis en œuvre
En ce qui concerne l’aspect technique, le contrôle d’accès se divise en trois groupes : les fichiers en lecture seule, les données lisibles et modifiables, et les ressources exécutables. Mais, selon le type de fichier avec lequel vous travaillez, ceux-ci peuvent varier considérablement. Cela étant dit, vous souhaitez toujours qu’ils soient mis en œuvre selon la procédure opérationnelle approuvée au préalable. Plus précisément, le système doit appliquer des protocoles précis à plusieurs étapes.
Premièrement, il doit identifier l’identifiant du sujet. Cet identifiant indique au système qui a demandé l’accès.
L’étape suivante consiste à identifier la personne derrière la demande, généralement effectuée via un processus d’authentification.
En supposant que l’étape d’authentification ne l’arrête pas, l’étape suivante consiste à vérifier la demande par rapport à la liste de contrôle d’accès. C’est là que le système s’assure que la personne derrière la demande a l’autorité pour accéder aux ressources qu’elle sollicite. De plus, le système détermine le niveau d’accès à accorder à cette personne.
Enfin, le système doit toujours inclure des mécanismes d’audit permettant de détecter et d’examiner les failles et faiblesses potentielles. Grâce à ceux-ci, vous devriez pouvoir détecter les façons dont quelqu’un pourrait contourner les restrictions d’accès avant qu’il ne le fasse.
Ce qui fragilise le contrôle d’accès
Pour comprendre comment protéger le système, vous devez d’abord comprendre comment le compromettre, n’est-ce pas ? Tout à fait. Dans cet esprit, mettons tout à plat et découvrons ce qui fragilise le contrôle d’accès.
Tout d’abord, il existe plusieurs façons pour les serveurs de fournir et de refuser les droits de demander certaines ressources. Celles-ci incluent les cookies de session, les tokens JWT, et bien plus encore. Comme nous l’avons établi précédemment, lorsque des utilisateurs demandent l’accès à des ressources spécifiques, le système s’assure d’abord qu’ils peuvent accéder à ces ressources avant d’exécuter la demande. La partie « vérification » peut être effectuée via des appels GET ainsi que différentes méthodes HTTP comme POST/PUT/DELETE. C’est là que réside le problème. Étant donné que les développeurs doivent sécuriser chaque point de terminaison avec chaque méthode HTTP possible, il est facile d’en oublier au moins un (ou plus).
En d’autres termes, le contrôle d’accès « défaille » lorsque des intrus parviennent à demander avec succès l’accès à quelque chose auquel ils ne devraient pas avoir accès. La plupart du temps, cela se produit lorsque les développeurs ne sécurisent pas les protocoles d’autorisation. L’exemple le plus courant serait des points de terminaison sur des sites qui renvoient des erreurs 403 interdites, qui peuvent ensuite être contournées en ajoutant un en-tête X-Forwarded-For : “127.0.0.1”.
Un autre exemple typique serait les anciens répertoires de la phase de développement qui auraient dû être supprimés ou protégés mais qui ne l’ont pas été.
Les utilisateurs moins expérimentés peuvent également stocker des mots de passe en texte brut dans le système. Ainsi, lorsque le système (généralement l’ordinateur) est compromis, les hackers peuvent également accéder à d’autres systèmes en utilisant ces mots de passe.
D’autres fois, les gens s’appuient sur des mots de passe faibles qui, même sans exposition accidentelle, peuvent être facilement déchiffrés, permettant ainsi un contrôle d’accès défaillant.
Et cela sans tenir compte des attaques intentionnelles contre le contrôle d’accès, qui constituent un tout autre problème.
Exemples de contrôle d’accès défaillant
Les vecteurs d’attaque possibles que les hackers peuvent adopter pour compromettre le contrôle d’accès sont trop nombreux pour être comptés. Cela étant dit, ils fonctionnent généralement selon les mêmes principes.
Absence de restriction d’accès aux URL
L’attaque de contrôle d’accès la plus courante se produit lorsqu’une URL contourne l’authentification, trompant le système pour lui faire croire qu’il a déjà été authentifié. En utilisant des connaissances sur le format et les modèles, les hackers sont capables d’écrire l’URL de pages privilégiées qui n’ont pas été correctement configurées.
Pour vous donner un exemple, imaginez qu’un petit poisson se connecte. Sa page principale ressemblerait à quelque chose comme ceci :
https://webdevsagainsthackers.net/fish_login.htmlVous remarquez quelque chose de bizarre (voulu cette fois-ci) ? L’URL affiche fish_login.html comme page principale.
Tout ce que les hackers ont à faire dans ce cas pour obtenir un accès requin à part entière, c’est modifier l’URL comme suit :
https://webdevsagainsthackers.net/shark_login.htmlÀ ce stade, les attaquants ont pu obtenir un accès requin en ne faisant rien d’autre que modifier l’URL. Facile ? Certes. Mais efficace contre les développeurs inexpérimentés néanmoins.
Références directes non sécurisées aux objets (IDOR)
Celui-ci est un peu plus complexe. Vous voyez, il existe plusieurs façons pour des agents malveillants d’accéder au codage brut d’une application web. Certaines parties de ce code peuvent révéler comment votre base de données est organisée en termes de format, de modèle, et bien plus encore. Avec seulement ces quelques éléments, des hackers compétents peuvent exposer davantage d’informations à des investigations supplémentaires.
Dans l’exemple suivant, vous vous connectez à votre compte sur un site web et vous regardez sa page principale. Dans la barre d’adresse, vous voyez une URL comme celle-ci :
https://webdevsagainsthackers.net/index.php/view?account=4200Qu’avons-nous ici ? Quelque chose qui ressemble à une longue liste de comptes, et vous êtes le numéro 4200 dans la base de données.
À première vue, rien de suspect. Mais tout ce qu’un agent malveillant doit faire pour accéder aux comptes d’autres utilisateurs, c’est mettre un numéro de compte différent. Parfois (plus souvent que cela ne devrait l’être), les comptes administrateur(s) sont attribués aux premiers 1 à 10 numéros. Ainsi, on modifie comme suit :
https://webdevsagainsthackers.net/index.php/view?account=1et de mauvais utilisateurs pourraient être en mesure d’accéder aux comptes administrateur.
« Attendez une seconde, cela ne semble pas si différent de l’attaque précédente ? » Vous avez raison. Mais vous avez également tort.
La différence ici est que, dans ce cas, les hackers exploitent les références d’objets. La plupart des applications web utilisent des noms de page par défaut basés sur la configuration MVC (modèle, vue et contrôleur). Parce que c’est le cas, les hackers pourraient être en mesure d’accéder au code source de ces applications web.
Considérez la section À propos de nous que la plupart des sites web possèdent. L’adresse ci-dessous montre que toutes les pages se terminent par .htm (ou quelque chose du genre) :
https://webdevsagainsthackers.net/against/default.aspx?content=about_us.htmLes hackers savent que la partie default.aspx.cs est la page principale et pourraient vouloir investiguer davantage.
En utilisant une attaque par octet nul (./) , ils peuvent tromper le code du navigateur pour lui faire croire que l’URL est complète. La chaîne suivant l’octet nul permet aux attaquants de révéler le contenu de n’importe quel fichier intégré :
https://webdevsagainsthackers.net/against/default.aspx?content=%20./default.aspx.cs%00.htm
Dans cet exemple, les hackers ont pu accéder à une page entière de code source de default.aspx.cs. Bien sûr, cela est possible avec n’importe quel nom de page par défaut.
Les références directes aux objets peuvent également apparaître dans un code d’erreur. Tout ce que les hackers ont à faire, c’est manipuler des entrées pour découvrir quelles exceptions/erreurs pourraient apparaître et ce qu’elles pourraient indiquer. Cela leur fournit davantage d’informations dont ils ont besoin pour effectuer des recherches dans l’URL.
Exemples réels de BAC
Encore une fois, étant donné que le BAC est aujourd’hui la principale menace de sécurité logicielle, même les plus grands géants des médias n’ont pas été épargnés dans le passé. En voici quelques exemples :
Snapchat. Gibson Security a détecté des vulnérabilités de contrôle d’accès dans le système Snapchat qui ont été initialement ignorées comme étant sans conséquence. Moins d’une semaine plus tard, des énumérations par force brute avaient révélé 4,6 millions de noms d’utilisateurs et de numéros de téléphone. Il va sans dire que les utilisateurs concernés n’étaient pas satisfaits de cette fuite de données, pas du tout.
Pages professionnelles Facebook. Laxman Muthiyah a découvert que des utilisateurs malveillants pouvaient envoyer une requête pour s’attribuer des droits d’administrateur sur certaines pages Facebook. Étant donné que Facebook n’assurait pas des mesures de contrôle d’accès sécurisées, les hackers n’avaient qu’à utiliser une requête comme celle-ci :
Request:-
POST //userpermissions HTTP/1.1
Host: graph.facebook.com
Content-Length: 245
role=MANAGER&user=&business=&access_token=
Response:-
true
et ils se rendaient administrateurs de la page. Comme vous pouvez l’imaginer, avec ce nouveau privilège, ils pouvaient refuser l’accès aux véritables administrateurs/gestionnaires de la page.
Comment prévenir le BAC
Pour garantir un contrôle d’accès efficace, vous devez d’abord vous assurer que le système l’applique via du code côté serveur fiable ou une API sans serveur. Ce faisant, vous pourrez empêcher les hackers de modifier le contrôle d’accès ou les métadonnées.
En dehors de cela, les étapes suivantes vous aideront à prévenir le contrôle d’accès défaillant :
- Vérifiez les autorisations et assurez-vous qu’elles sont correctes. Bien entendu, l’astuce est d’être minutieux, en vérifiant chaque fichier. En cas de doute, suivez le principe du moindre privilège : assurez-vous que seules les personnes qui ont besoin de modifier des fichiers spécifiques ont un accès écriture à ces fichiers.
- Désactivez la mise en cache côté client sur les pages restreintes. Dans le cas contraire, des utilisateurs non autorisés pourraient être en mesure d’accéder à nouveau à ces pages.
- Évitez les mécanismes dits de contrôle d’accès présentationnel. Le simple fait qu’il n’y ait pas de bouton visible conduisant les utilisateurs vers des pages restreintes ne signifie pas que les attaquants ne seront pas en mesure de les trouver. C’est essentiellement la sécurité par l’obscurité, un principe qui NE RÉSISTE PAS aux hackers sérieux. Protégez plutôt les pages sensibles derrière une authentification.
- Refusez l’accès à toutes les fonctions par défaut. De cette façon, vous aurez plus de facilité à maintenir les autorisations en ordre. De plus, assurez-vous d’utiliser des listes de contrôle d’accès ainsi que des pratiques d’authentification basées sur les rôles.
- Ne nommez pas les pages cibles de manière significative. Lorsque vous le faites, vous aidez les intrus à les identifier. Utilisez plutôt des paires clé-valeur qui référencent les objets.
Résumé rapide
On ne gagne pas la première place du classement des menaces de sécurité logicielle sans causer de sérieux dégâts et en permettre encore davantage à l’avenir. À moins que nous ne l’ayons pas clairement dit : vous devez prendre la menace du contrôle d’accès défaillant au sérieux, ou vous risquez de ne pas apprécier l’alternative. Cela dit, à condition de savoir à quoi vous avez affaire, comment le prévenir et comment combattre le BAC, vous devriez vous en sortir.
Contrôle d’accès sécurisé : le guide de référence ultime pour prévenir le BAC
