Le contrôle d’accès défaillant – catégorie de vulnérabilité qui figure régulièrement dans la liste des 10 principaux risques de sécurité des applications Web de l’OWASP – représente actuellement le défi le plus important pour la sécurité des applications. Le recours excessif à des solutions automatisées pour relever ces défis crée un faux sentiment de sécurité et pourrait avoir de graves conséquences pour les détenteurs d’applications.

Les failles dans le contrôle d’accès permettent aux utilisateurs d’accéder à des données sensibles et leur confèrent la possibilité d’effectuer des actions au-delà des autorisations prévues. Les conséquences de ces vulnérabilités peuvent conduire à la divulgation, à la modification, voire à la destruction des données.

Dans cet article, nous verrons pourquoi les vulnérabilités du contrôle d’accès persistent souvent et ce même après les analyses et évaluations de vulnérabilité, ainsi que l’importance des tests d’intrusion manuels pour une détection et une atténuation efficaces.

Qu’est-ce que le contrôle d’accès ?

Le contrôle d’accès peut être considéré comme une vérification d’autorisation, garantissant que l’accès aux ressources et la capacité d’effectuer des actions sont accordés à certains utilisateurs (par exemple, les administrateurs) et pas à d’autres (les utilisateurs ordinaires par exemple). Ces contrôles sont généralement effectués après le processus d’authentification, au cours duquel l’identité déclarée d’un utilisateur est vérifiée.

En matière de sécurité des applications web, le contrôle d’accès est étroitement lié au contenu, à l’utilisation prévue des fonctionnalités et aux différents rôles des utilisateurs. Il peut s’agir, par exemple, d’empêcher un utilisateur peu privilégié d’exécuter des fonctions administratives, d’empêcher un utilisateur d’accéder aux ressources d’un autre utilisateur, ou de tout contrôle qui accorde ou refuse l’accès à des ressources ou à des fonctions selon des facteurs contextuels.

Lorsqu’il s’agit d’applications vastes et complexes contenant de nombreux rôles et fonctionnalités d’utilisateurs, les contrôles d’accès peuvent rapidement devenir difficiles à mettre en œuvre correctement.

Qu’est-ce qu’un contrôle d’accès défaillant ?

Un contrôle d’accès défaillant est tout simplement et comme son nom l’indique, un contrôle d’accès qui ne fonctionne pas comme prévu. Il s’agit essentiellement du contraire de ce que nous avons mentionné ci-dessus, avec quelques exemples détaillés à suivre.

Référence directe à l’objet non sécurisée (IDOR)

Considérons une application qui permet aux utilisateurs réguliers de consulter et de modifier les informations relatives à leur compte. Un identifiant est attribué à chaque compte. Lorsqu’une demande de modification est envoyée, l’application détermine quel compte doit être mis à jour en fonction de l’identifiant inclus dans la demande. Dans ce scénario, un attaquant pourrait manipuler une requête sortante destinée à mettre à jour son compte, en modifiant l’identifiant de l’utilisateur pour en faire celui d’une victime.

Sans contrôle d’accès en place, le compte de la victime se verrait ainsi modifié – une vulnérabilité IDOR avec un impact direct sur l’intégrité. À partir de là, la situation peut rapidement s’aggraver. Supposons que l’attaquant modifie l’adresse électronique de la victime et qu’il demande ensuite une réinitialisation du mot de passe. Cela lui permettrait de définir un nouveau mot de passe et, finalement, de prendre le contrôle du compte de la victime.

Maintenant que nous avons obtenu l’accès au compte d’un autre utilisateur, il convient de clarifier deux termes supplémentaires qui reviennent souvent au sujet du contrôle d’accès défaillant : l’escalade horizontale et l’escalade verticale des privilèges.

L’escalade horizontale des privilèges

L’escalade horizontale des privilèges consiste à obtenir l’accès aux ressources d’un autre compte avec des autorisations similaires. Dans l’exemple de la section précédente, si le compte de la victime disposait d’autorisations similaires à celles de l’utilisateur attaquant (c’est-à-dire un utilisateur normal), il s’agirait également d’une escalade horizontale des privilèges. En bref, à part l’accès aux ressources d’un autre compte, l’attaquant n’obtient aucune autorisation supplémentaire.

L’escalade verticale des privilèges

L’escalade verticale des privilèges désigne l’accès aux ressources d’un autre compte disposant de plus d’autorisations. Dans l’exemple de la section précédente, si le compte de la victime disposait d’autorisations plus élevées (par exemple, modérateur ou administrateur), il s’agirait d’une escalade verticale des privilèges. L’attaquant peut abuser des autorisations supplémentaires pour lancer d’autres attaques contre l’application.

Traversée de chemin/répertoire

Considérons une application qui permettrait aux utilisateurs de visualiser leurs factures à l’aide d’une fonctionnalité de prévisualisation intégrée. Les factures sont stockées sur le même serveur que l’application, au chemin absolu suivant :

/var/www/html/vulnerable-application/invoices/

Lorsqu’un utilisateur clique sur l’une des factures affichées sous son profil, la requête suivante est envoyée :

La prévisualisation fonctionne en ajoutant la valeur du paramètre « file » au chemin d’accès absolu donné. Il récupère ensuite le contenu de ce fichier et le renvoie à l’utilisateur demandeur.

/var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf

Cependant, comme dans le cas du scénario IDOR, un attaquant pourrait également capturer la requête sortante et modifier son paramètre « file » en un fichier qui n’est pas destiné à être récupéré.

En l’absence de contrôle d’accès, l’attaquant essaierait alors de récupérer le document :

/var/www/html/vulnerable-application/invoices/../../../../../etc/hosts

La séquence point-point-slash (../) recule d’un répertoire dans le chemin d’accès (traverse le répertoire parent). Nous avons cinq de ces séquences, ce qui signifie que nous nous retrouvons à la racine du système de fichiers (/). À partir de là, nous entrons dans le répertoire etc, d’où nous demandons le fichier hosts. Le fichier hosts, un fichier par défaut qui établit une correspondance entre les noms d’hôtes et les adresses IP, ne serait probablement pas le premier choix d’un attaquant. Nous l’utilisons ici pour montrer la possibilité de récupérer des fichiers en dehors du répertoire de l’application, ce qui est également connu sous le nom d’inclusion de fichiers locaux. Un pirate essaierait plutôt de récupérer des fichiers sensibles, à la fois à l’intérieur et à l’extérieur du répertoire de l’application.

Pas d’escalade ? Désescaladez !

En guise de dernier exemple, j’évoquerai un cas concret tiré de l’évaluation récente d’un client. L’application comportait plusieurs rôles d’utilisateurs, tous apparemment bien configurés et correctement séparés. Toutes les tentatives d’élévation des privilèges d’un utilisateur normal, d’accès à des ressources non souhaitées et d’exécution d’actions privilégiées étaient empêchées grâce aux nombreux contrôles d’accès mis en place.

Toutefois, après une analyse approfondie des différents rôles des utilisateurs, nous avons constaté une anomalie. Par exemple, certains rôles pouvaient modifier et supprimer les comptes d’autres utilisateurs, mais ne pouvaient le faire que pour des comptes ayant des privilèges inférieurs aux leurs. Les utilisateurs disposant de ces autorisations ne pouvaient pas non plus effectuer ces actions sur leur propre compte. Ce qui a été négligé, c’est la possibilité d’attribuer à des utilisateurs disposant de privilèges élevés un rôle moins privilégié, ce qui aurait pour effet d’effacer tous les privilèges et de rétrograder leurs comptes. Ces comptes rétrogradés remplissent alors la condition pour être modifiés et supprimés par un compte techniquement moins privilégié.

Le défi que représente la mise en œuvre correcte des contrôles d’accès augmente avec la complexité de l’application, et il en va de même pour l’identification des problèmes de contrôle d’accès. Pour la détection de ces contrôles, les tests de sécurité manuels constituent la meilleure approche car ils impliquent une compréhension plus approfondie du contexte et de l’utilisation prévue de l’application.

Les limites de l’analyse de la vulnérabilité

Les scanners de vulnérabilité sont une solution populaire afin d’identifier les failles dans les applications. Cependant, le fait de s’en remettre uniquement à eux crée un faux sentiment de sécurité pour les détenteurs d’applications. Bien que ces scanners puissent fournir des résultats de manière continue et rapide, ils sont limités dans leur capacité à détecter de nouveaux vecteurs d’attaque ou d’autres vulnérabilités nécessitant de l’intuition et du raisonnement.

Pour illustrer ce point, comparons les vulnérabilités liées au contrôle d’accès à une autre vulnérabilité courante présentant une complexité similaire et nécessitant un raisonnement humain : les vulnérabilités liées à la logique d’entreprise.

Les failles dans la logique d’entreprise surviennent lorsque la conception, la mise en œuvre ou les processus internes d’une application s’écartent de l’utilisation prévue. Parmi les exemples les plus courants, citons la commande d’une quantité négative d’un produit ou l’utilisation à plusieurs reprises du même code de réduction.

Même avec ces exemples simples, les limites d’un scanner de vulnérabilité apparaissent clairement. Un scanner ne serait pas en mesure de discerner le comportement attendu de l’application. De son point de vue, un nombre négatif reste un nombre et l’utilisation répétée d’une certaine fonctionnalité n’est pas nécessairement mauvaise. Contrairement à d’autres vulnérabilités comme le cross-site scripting (XSS) et l’injection SQL, un scanner ne peut pas simplement fournir une entrée et rechercher un modèle prédéfini dans la réponse de l’application pour déterminer si quelque chose est vulnérable.

Du point de vue d’une sécurité offensive, l’identification des vulnérabilités relatives aux contrôles d’accès défaillants ou à la logique de l’entreprise nécessite le même état d’esprit et la même compréhension contextuelle de l’application. Dans de nombreux cas, les deux catégories se recoupent. Par exemple, lors de l’évaluation d’une fonctionnalité de téléchargement de fichiers, un exemple de test consisterait à télécharger un type de fichier inattendu, un fichier SVG contenant une charge utile JavaScript par exemple, alors que seuls les fichiers image sont autorisés. Si le SVG répond aux critères généraux de l’image, le JavaScript qu’il contient n’est pas censé être analysé par le navigateur de l’entreprise victime. Si tel est le cas, s’agit-il d’une vulnérabilité dans la logique d’entreprise ou d’un contournement des contrôles d’accès ?

Supposons maintenant qu’une fonctionnalité de téléchargement de fichiers empêche correctement tous les fichiers non souhaités d’être téléchargés. Un exemple de test approprié consisterait à télécharger un fichier autorisé vers un emplacement non prévu, comme un répertoire, pour lequel l’utilisateur qui télécharge n’a pas les droits d’écriture. Ce scénario indiquerait-il un contournement des contrôles d’accès ou une faille dans la logique commerciale de l’application ? On peut argumenter dans les deux cas.

Dans les cas évoqués, il est essentiel de comprendre l’objectif visé par la fonctionnalité de téléchargement de fichiers afin de déterminer si nous enfreignons des règles de gestion ou des contrôles d’accès.

Dans un scénario réel, une complexité supplémentaire sous la forme de droits, de rôles, d’intégrations externes, de bibliothèques tierces, de dépendances, etc. serait également ajoutée.

Cette complexité spécifique au contexte consiste à déterminer quel utilisateur devrait avoir accès à quel objet, quelles données sont sur le point d’être divulguées, quand les conditions de course peuvent être exploitées, où les possibilités d’ingénierie sociale sont probables, etc.

Atténuer les vulnérabilités du contrôle d’accès grâce aux tests d’intrusion

Pour détecter et atténuer les vulnérabilités du contrôle d’accès et d’autres failles logiques, les détenteurs d’applications doivent compléter les solutions d’analyse automatisées avec des tests d’intrusion manuels et un raisonnement humain. SWAT d’Outpost24 est une solution de test d’intrusion en tant que service (PTaaS) qui aide les détenteurs d’applications à atteindre un niveau plus élevé de sécurité et de détection des risques. SWAT offre des tests manuels étendus, personnalisés et continus, avec une option d’automatisation des analyses pour une surveillance continue. Contrairement aux tests traditionnels, les résultats d’Outpost24 sont fournis en temps réel via un portail dédié qui vous met directement en contact avec nos experts en sécurité. Le service élimine également le risque de faux positifs car tous les résultats sont examinés par un pen-testeur expérimenté.

Échangez avec un expert et découvrez SWAT plus en détails.