08. Désynchronisation et request smuggling

Comprendre le mécanisme

Une désynchronisation apparaît lorsque des composants d’une chaîne ne s’accordent pas sur les frontières ou le sens des requêtes. Sur des connexions réutilisées, cette divergence peut affecter une demande ultérieure ou contourner une hypothèse du frontal. Le risque dépend de la chaîne entière, y compris des traductions HTTP/2 vers HTTP/1.1 ; le protocole vu par le navigateur ne décrit pas nécessairement le dernier saut.

Raisonner et vérifier

La défense privilégie des parseurs cohérents, à jour et stricts, ainsi qu’un traitement explicite des messages non conformes. Ne considérez pas une règle WAF ou un mot-clé bloqué comme une preuve complète. Les essais de délimitation doivent rester dans une chaîne de test dédiée, afin d’observer précisément les connexions et les effets sans perturber d’autres utilisateurs.

Frontières divergentes

Le risque dépend d’interprétations différentes des messages. Le problème porte ici sur les frontières des requêtes. Le cœur du problème est un désaccord sur les limites du message. Un frontal qui termine à l’octet 100 et un backend à 140 ne traitent pas le même découpage des échanges.

Système complet

La chaîne complète proxy/backend compte. L’écart peut se situer entre composants. Reproduisez la version exacte du proxy, sa configuration et le serveur d’origine. Tester seulement une bibliothèque PHP laisse hors périmètre les interprétations déjà faites par CDN et reverse proxy avant son intervention.

Canal mutualisé

Une connexion mutualisée peut toucher un autre échange. Les frontières incorrectes peuvent affecter des messages suivants. Une connexion partagée peut faire rencontrer les octets restants d’un échange avec une autre demande. Le laboratoire doit donc contrôler l’usage du canal et ne jamais exposer d’autres visiteurs aux tests.

Mises à jour

Les mises à jour des intermédiaires comptent. La correction doit viser la couche concernée. Des corrections de parseur et de traduction peuvent changer les refus. Gardez les intermédiaires maintenus et rejouez les fixtures pertinentes lors d’une évolution, sans supposer que l’application seule porte la réparation.

Ambiguïtés refusées

Le refus d’ambiguïtés réduit le risque. Des interprétations divergentes doivent être évitées. Adoptez des règles strictes compatibles avec les protocoles utilisés plutôt que laisser chaque composant deviner. Vérifiez le comportement réel en présence de données malformées, y compris l’état de connexion après rejet.

Versions différentes

Les conversions protocolaires doivent être vérifiées. La traduction peut introduire ou conserver une ambiguïté. L’utilisation de HTTP/2 côté navigateur n’exclut pas HTTP/1.1 derrière un proxy. Dessinez les traductions et testez leurs frontières ; la version du premier saut ne décrit pas tous les autres.

Isolation

Un laboratoire doit isoler les autres utilisateurs. Le test ne doit pas perturber des tiers. Les expériences doivent utiliser ressources et connexions dédiées avec contenus factices. Prévoyez une remise à zéro entre cas afin qu’une tentative précédente ne fausse pas la lecture de la suivante.

Reproductibilité

La reproduction doit préciser les versions. Versions et options influencent les comportements. Enregistrez les versions exactes, les options et la topologie avec les résultats. Un refus observé sur une chaîne différente ne démontre pas la même propriété pour celle effectivement déployée chez l’hébergeur.

Rejet observé

Un rejet doit être vérifié à chaque frontière pertinente. L’état de connexion et les couches atteintes demandent des observations. Vérifiez quelle couche refuse et si le backend reçoit quelque chose. Un statut d’erreur final n’exclut pas une interprétation partielle différente ; les journaux corrélés et mesures de laboratoire complètent le résultat client.

Politique cohérente

Une politique cohérente est une propriété du système. Les règles ont un périmètre et des limites. La sécurité attendue dépend de l’accord des composants sur les messages. Attribuez un responsable aux changements de proxy et de backend afin que cette propriété reste vérifiée lors des releases.

Atelier guidé : lire, expliquer et vérifier le code

{
  "frontendInterpretation": "message ends at offset 100",
  "backendInterpretation": "message ends at offset 140",
  "sharedConnection": true
}

Les offsets différents constituent l’indice principal ; la connexion partagée augmente les conséquences possibles sur les échanges suivants. Il ne suffit pas de répondre que le JSON d’observation est valide. Expliquez la divergence puis définissez une reproduction isolée et les points de mesure nécessaires pour vérifier le refus cohérent.

Les credentials ne corrigent pas cette divergence. Des frontières différentes sur un canal réutilisé peuvent désynchroniser les échanges. Le hasard n’établit pas une règle commune. Le protocole doit définir la décision, pas une heuristique libre.

Travail pratique : Rédigez une procédure de revue des versions, de la normalisation et de la réutilisation des connexions sur votre chaîne de laboratoire.

Critères de correction : Confrontez les journaux de chaque saut sur un corpus contrôlé, vérifiez les refus et ajoutez des tests après mise à jour. Conservez topologie, versions et conditions d’essai : un résultat sur un serveur seul ne couvre pas la chaîne.