Lors de l'audit de sécurité d'une application web, une vulnérabilité classique consiste à se fier exclusivement aux données renvoyées par une API pour gérer l'affichage de fonctionnalités restreintes (comme un accès Premium ou des téléchargements réservés). Cette approche repose sur un postulat erroné : l'intégrité des données reçues par le client. Nous allons explorer comment un proxy de débogage peut être utilisé pour intercepter et modifier ces données afin de tester la robustesse des mécanismes d'autorisation.

Analyse du flux de données

Le vecteur d'attaque ou de test commence par l'observation des échanges entre le navigateur et le serveur. Dans de nombreux cas, une application charge les métadonnées d'un contenu, mais attend une validation du profil utilisateur avant d'afficher les liens sensibles. Si le client reçoit une réponse chiffrée ou masquée, il est probable qu'un appel ultérieur à un point de terminaison de type /profile ou /permissions détermine la logique de déchiffrement côté frontend.

Interception et modification de la charge utile (Payload)

Prenons l'exemple d'un point de terminaison /api/v1/account_info. Une réponse standard pourrait indiquer un accès limité :

{
   "status": "success",
   "user_data": {
       "user_id": 9982,
       "email": "test@exemple.com",
       "account_type": "free",
       "privileges": {
           "can_download": false,
           "is_premium": 0,
           "tier": "basic"
       },
       "subscription_end": "2023-01-01 00:00:00"
   }
}

Pour tester la réaction de l'interface, nous pouvons modifier localmeent ces valeurs. En changeant account_type en "pro" et is_premium à 1, nous simulons un profil avec des droits élevés. L'objectif est de vérifier si le frontend déverrouille l'accès aux ressources uniquement sur la base de ce JSON.

Mise en œuvre avec un outil de Proxy (Fiddler)

Pour automatiser cette substitution, on utilise la fonctionnalité de "Réponse Automatique" (AutoResponder). Le processus consiste à capturer la requête légitime, puis à configurer une règle qui renvoie un fichier JSON local modifié au lieu de transmettre la requête au serveur réel.

1. Activer l'interception du trafic HTTPS dans les paramètres du proxy.
2. Identifier la requête vers l'API cible dans le flux de trafic.
3. Créer une règle de correspondance (Match Rule) pour l'URL exacte.
4. Lier cette règle à un fichier .json contenant la réponse falsifiée.

Résolution des contraintes de sécurité CORS

Lorsqu'on simule une réponse depuis un proxy, le navigateur peut bloquer la requête en raison des politiques de partage de ressources entre origines multiples (CORS), car les en-têtes de sécurité attendus pourraient manquer. Pour pallier cela, il est nécessaire d'injecter dynamiquement des en-têtes dans la réponse interceptée via un script de manipulation de session.

static function OnBeforeResponse(oSession: Session) {
   if (oSession.uriContains("api.target-app.local")) {
       oSession.oResponse["Access-Control-Allow-Origin"] = "*";
       oSession.oResponse["Access-Control-Allow-Credentials"] = "true";
       oSession.oResponse["Access-Control-Allow-Headers"] = "Content-Type, Authorization, X-Requested-With";
       oSession.oResponse["Access-Control-Allow-Methods"] = "GET, POST, OPTIONS";
   }
}

Ce script C# au sein du proxy assure que le navigateur accepte les données injectées comme provenant d'une source autorisée. Une fois ces en-têtes en place, le rechargement de la page applicative forcera l'interface à traiter les données manipulées, révélant ainsi si le contrôle d'accès est purement cosmétique (côté client) ou s'il est renforcé par une validation cryptographique côté serveur.