L'injection HTML se produit lorsqu'un pirate parvient à insérer des balises HTML arbitraires dans une page Web, ce qui peut entraîner des attaques XSS ou une manipulation de la structure de la page. Bien que moins grave que l'injection de script, l'injection HTML peut néanmoins permettre diverses attaques, notamment l'usurpation de contenu et les attaques basées sur le style. La prévention nécessite une validation appropriée des entrées et un encodage correct des sorties.
L'injection HTML est une faille par laquelle une application insère dans une page une entrée contrôlée par l'attaquant sans l'encoder, ce qui permet à l'attaquant d'ajouter ou de modifier le balisage HTML, les balises, les attributs et la structure. C'est la catégorie plus large dont le cross-site scripting est le cas le plus grave : si le balisage injecté peut inclure un script exécutable ou un gestionnaire d'événements, il devient du XSS, mais si le filtrage bloque le script tout en autorisant d'autres balises, il reste à l'attaquant une pure injection HTML. Même sans exécuter de code, un attaquant peut injecter des liens, des formulaires, des images, des iframes et des styles. La cause racine est la même, des données non fiables atteignant la sortie HTML sans échappement, que la source soit un paramètre d'URL, un champ de formulaire ou un contenu stocké.
Bien qu'elle soit souvent jugée moins grave que l'injection de script, l'injection HTML est loin d'être inoffensive. Un attaquant peut greffer un faux formulaire de connexion convaincant sur une page de confiance et envoyer les identifiants vers son propre serveur, une forme de phishing sur la page qui affiche encore le vrai domaine dans la barre d'adresse. Le contenu injecté peut défigurer la page, insérer un texte trompeur ou des images offensantes, superposer des éléments pour détourner les clics, ou charger des ressources externes. Un balisage laissé ouvert (dangling markup) et des images injectées peuvent aussi divulguer des parties de la page ou des jetons anti-CSRF à un attaquant. Et comme les filtres qui suppriment les balises de script tout en autorisant d'autres balises sont courants, l'injection HTML sert fréquemment de tremplin ensuite transformé en XSS complet.
La correction reflète celle du XSS : ne placez jamais une entrée non fiable dans une page sous forme de balisage brut. Encodez la sortie pour le contexte HTML afin que les balises s'affichent comme du texte visible, validez les entrées, et lorsque vous devez accepter du contenu riche, faites-le passer par un sanitizer à liste d'autorisation stricte qui supprime les balises inconnues, les gestionnaires d'événements et les attributs dangereux. Une Content Security Policy limite les dégâts des ressources injectées. cside opère à une autre couche, en surveillant les scripts third-party qu'une page charge : son méthode Script analyse chaque charge utile, peut bloquer les comportements malveillants en temps réel et conserve des traces forensiques qui répondent à PCI DSS 6.4.3 et 11.6.1. Il complète, sans les remplacer, l'encodage et l'assainissement dans vos propres modèles.
Elles se recoupent mais ne sont pas identiques. Toutes deux découlent d'une entrée non échappée atteignant la page. Le XSS exécute spécifiquement du JavaScript d'attaquant, tandis que l'injection HTML couvre tout balisage injecté, y compris les cas où les scripts sont filtrés mais où d'autres balises s'affichent encore. Chaque XSS est une forme d'injection HTML, mais toute injection HTML n'aboutit pas à l'exécution de script.
Oui. Sans le moindre script, un attaquant peut injecter un faux formulaire de connexion pour du phishing sur la page, défigurer le contenu, intégrer des liens ou des images trompeurs, ou utiliser un balisage laissé ouvert et du CSS pour exfiltrer des données telles que des jetons anti-CSRF. L'usurpation de contenu sur un domaine de confiance est convaincante précisément parce que l'URL est authentique.
We answer client-side security questions every day. Bring yours.