Absence de restriction d’accès aux URL : C’est toujours d’actualité

Voici quelques brèves réflexions sur un vieux problème. Si vous êtes un professionnel de la sécurité des applications à plein temps, arrêtez de lire. Vous savez tout sur ce sujet, vous connaissez probablement cinq façons différentes de le décrire et d’en parler, et vous avez sans aucun doute un kit d’outils préférés prêts à l’emploi pour explorer ce type de problème dans chaque type d’application auquel vous êtes confronté.

Si vous effectuez un travail de sécurité qui est adjacent à l’application, comme des tests de pénétration ou si vous essayez d’évaluer votre propre posture de sécurité, voici quelques idées sur la façon d’identifier les problèmes dans une catégorie de vulnérabilité commune pour les applications web modernes.

Il y a bien longtemps, il était souvent simple de trouver des parties d’applications dépourvues de contrôle d’accès. Les noms de certaines de ces techniques étaient forced-browsing, Google-Dorks, deeplink discovery, etc. Les outils utilisés étaient DirBuster, Burp Suite’s « Discover Content », Google, Nikto, et find/grep. Certains de ces outils sont encore utilisés régulièrement, ainsi que des itérations plus récentes comme Gobuster et ffuf.

Il était également possible de modifier simplement /login à /home ou simplement essayer de lancer des composants supplémentaires comme /adminou /util à la fin des chemins. Avec un peu de chance, Apache ou IIS a été configuré pour aider un attaquant en fournissant un index de répertoire.

Figure 1 – Enregistrements de cartes de pointage non authentifiés

Les testeurs peuvent penser que la découverte de ces éléments est hors de portée dans les applications contemporaines. Les testeurs peuvent se dire des choses telles que :

  • Les applications n’ont plus de pages séparées, je ne peux donc pas mettre /admin à la fin d’un chemin et attendre un résultat autre qu’une réponse 404.
  • L’API REST, à moins qu’il ne s’agisse que de GET avec un paramètre de chemin, signifie que je n’arriverai jamais à rien sans connaître une incantation JSON secrète.
  • SOAP est complètement opaque.

Sans visiter le site snopes.com, je me permets d’aller de l’avant et de qualifier ce qui précède de « faux pour l’essentiel ».

Les applications ne sont peut-être pas votre gagne-pain, mais elles représentent tout de même une bonne partie de la surface d’attaque. Avant que les testeurs ne haussent les épaules et ne disent « ça a l’air nouveau, je vais passer à autre chose », les applications devraient être examinées de plus près. L’objectif est de repérer rapidement les contrôles d’autorisation manquants sans s’enfoncer dans les méandres. Il est encore possible de faire beaucoup avec un simple navigateur web et les outils de développement intégrés ; cependant, les proxys d’interception comme le Burp Suite sera un avantage, en particulier pour les recherches sur plusieurs fichiers/URL.

Chasse aux chemins d’accès

Cet exemple est un peu artificiel, mais il peut être partagé et provient des laboratoires de Portswigger. Une application réelle aura probablement le bundle JavaScript dans un fichier séparé et il sera minifié, mais ces transformations n’empêcheront pas l’utilisation de regex pour extraire tout ce qui ressemble à un chemin !

Lien : https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality-with-unpredictable-url

Figure 2 – Recherche de chemins pour les ressources administratives

Les fichiers intéressants peuvent avoir un nom généré par le framework comme 4f44a1bf1b35c2c4f326.js mais seront très probablement servis par le même hôte/domaine à cause de CORS et d’autres contrôles de sécurité du navigateur. Pour cette raison, il est probablement judicieux de dépasser rapidement les inclusions de scripts tiers. L’analyse des blobs peut être réalisée efficacement avec une expression régulière comme :

(\’| »|`)[A-z0-9_\(\)\?\&\[\]\#\-\~]*\/[A-z0-9_\(\)\?\&\[\]\#\-\~\/]*(\’| »|`)

L’expression ne trouvera pas tous les chemins d’accès qui pourraient être légaux dans une URL et elle n’est pas non plus exempte de faux positifs sur des chaînes qui ne sont pas des chemins d’accès. Elle permet cependant de rendre le travail de recherche dans un gros fichier plus abordable. Quelques extensions de Burp qui feront une partie de ce travail pour vous sont JS Link Finder et JS Miner.

JS Link Finder

Lien : https://portswigger.net/bappstore/0e61c786db0c4ac787a08c4516d52ccf

JS Miner

Lien : https://portswigger.net/bappstore/0ab7a94d8e11449daaf0fb387431225b

Armés d’informations sur les chemins possibles, différentes stratégies peuvent être employées. Pour accéder aux éléments dans l’application elle-même, il peut suffire d’ajouter des éléments de chemin aux fragments d’URL.

Exemple :

HTTPS://example.com/onlineStoreApp/#/searchProducts/byCatagory devient HTTPS://example.com/onlineStoreApp/#/administration/mangeUsers

C’est toujours aussi simple ! L’application se chargera de formater les requêtes API, etc. Par ailleurs, les fragments d’URL ne sont pas envoyés au serveur. L’essai de certains d’entre eux devrait passer inaperçu, du moins jusqu’à ce qu’une fonctionnalité soit déclenchée avec succès.

Pour en revenir à la lecture du code côté client, pour les applications utilisant REST, il y a de fortes chances que les chemins ou les composants de chemin soient proches du code responsable de l’appel au service. Même si vous n’êtes pas un magicien du JavaScript, le code peut être assez facile à comprendre. XMLHttpRequest et fetch().

Recherche de caractéristiques

Il n’est pas toujours aussi simple de rechercher des chemins d’accès. Un examen de la logique de l’application peut s’avérer nécessaire. Il est probable qu’une bonne partie de la découverte peut encore être effectuée sans avoir à s’enfoncer trop profondément dans un bourbier JavaScript. Cela n’a de sens que dans le contexte d’applications où le testeur a un certain accès ; cependant, il n’est pas rare d’avoir un certain accès (par exemple, toute application qui permet l’auto-enregistrement).

Pour cibler les caractéristiques au niveau du survol rapide, commencez par regarder ce qui est à l’écran. S’il existe des zones fonctionnelles de l’application telles que « Gérer le profil » ou « Consultation de produits », elles peuvent être reconnues dans les drapeaux de fonctionnalités. Ensuite, commencez à examiner les réponses de l’API. Pour SOAP ou autre, il peut être nécessaire de fouiller dans du XML, mais pour REST, l’élément intéressant sera probablement une réponse à quelque chose d’évident comme /users/me ou /users/{quelqueIdAssignedToYourAccount}. D’autres mots à surveiller ici sont « compte », « abonnement », « fonctionnalités », « sécurité » et « rôles ». La réponse HTTP à rechercher peut ressembler à l’exemple ci-dessous.

Figure 3 – Réponse de type REST pour les indicateurs de fonctionnalités

C’est vraiment le cas idéal. Aucune supposition n’est nécessaire et il suffit d’inverser certains booléens. La recherche de caractéristiques supplémentaires pourrait être un peu plus difficile si une réponse comme celle qui suit est trouvée.

Figure 4 – Réponse de type REST concernant les indicateurs de caractéristiques

Dans ce cas, la meilleure stratégie consiste généralement à rechercher les drapeaux observés et à voir si des noms similaires apparaissent dans le code à proximité. Il n’est pas vraiment nécessaire de comprendre le JavaScript qui est passé au crible, mais seulement de repérer des modèles. Dans ce cas, si l’application comporte des boutons intitulés « Service clientèle » et « Gérer le profil », la réponse ci-dessus indique qu’il faut rechercher dans le code les chaînes de caractères qui correspondent à une expression similaire à :

FN_[MT]_[A-Z]

Une fois que certaines caractéristiques ont été identifiées, il est temps de les ajouter ou de les modifier. La façon la plus évidente pour les utilisateurs de Burp Suite est d’utiliser les « règles de correspondance et de remplacement » dans les paramètres du proxy.

Figure 5 – Burp Match and Replace

Cette méthode présente des inconvénients évidents. En particulier, le motif remplacé peut apparaître ailleurs dans le code et entraîner un échec de chargement ou une mauvaise exécution de l’application.

Quelques bonnes pratiques Burp Suite permettront d’adopter une approche plus ciblée. L’un des objectifs pourrait être de s’assurer que seule la réponse à une demande spécifique est modifiée. Certaines applications peuvent avoir des dizaines de rôles ou d’attributions de permissions, et il serait utile de pouvoir les activer tous par programme sans avoir à écrire une règle de correspondance pour chacun d’entre eux. Reshaper est un exemple de plugin qui peut être utile dans ce domaine. Il s’agit d’un outil très flexible ; cependant, la flexibilité s’accompagne d’une grande complexité. Apprendre à travailler avec certains de ces outils si vous ne les utilisez pas fréquemment peut prendre un certain temps. Voici quelques alternatives qui pourraient être plus rapides à mettre en œuvre HTTP Mock et mon propre Réponse Tinker.

Reshaper

Lien : https://portswigger.net/bappstore/7bcec7656b5746e9a85c427f243e6d5a

HTTP Mock

https://portswigger.net/bappstore/42680f96fc214513bc5211b3f25fd98b

Réponse Tinker

Lien : https://trustedsec.com/blog/more-options-for-response-modification-with-responsetinker

Il s’agit là de quelques stratégies rapides pour trouver des domaines d’application qui pourraient manquer de contrôles d’autorisation, ou des cas où l’autorisation n’est effectuée que sur le front-end alors que les points d’extrémité de l’API sont mûrs pour les abus. L’expérience nous montre qu’il y a beaucoup de choses qui ne demandent qu’à être trouvées. Bonne chasse !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *