La inyección de HTML se produce cuando un atacante es capaz de insertar etiquetas HTML arbitrarias en una página web, lo que puede dar lugar a ataques XSS o a la manipulación de la estructura de la página. Aunque es menos grave que la inyección de scripts, la inyección de HTML puede permitir varios ataques, como la suplantación de contenido y los ataques basados en el estilo. La prevención requiere una validación de entrada y una codificación de salida adecuadas.
La inyección de HTML es un fallo en el que una aplicación inserta datos controlados por el atacante en una página sin codificarlos, lo que le permite añadir o alterar marcado HTML, etiquetas, atributos y estructura. Es la categoría más amplia dentro de la cual el cross-site scripting es el caso más grave: si el marcado inyectado puede incluir un script ejecutable o un manejador de eventos se convierte en XSS, pero si el filtrado bloquea el script y a la vez permite otras etiquetas, al atacante le queda pura inyección de HTML. Incluso sin ejecutar código, un atacante puede inyectar enlaces, formularios, imágenes, iframes y estilos. La causa raíz es la misma, datos no confiables que llegan a la salida HTML sin escapar, ya sea que la fuente sea un parámetro de la URL, un campo de formulario o contenido almacenado.
Aunque a menudo se valora por debajo de la inyección de scripts, la inyección de HTML dista mucho de ser inofensiva. Un atacante puede injertar un formulario de inicio de sesión falso y convincente en una página de confianza y enviar las credenciales a su propio servidor, una forma de phishing en la página que sigue mostrando el dominio real en la barra de direcciones. El contenido inyectado puede desfigurar la página, insertar texto engañoso o imágenes ofensivas, superponer elementos para secuestrar clics o traer recursos externos. El marcado colgante y las imágenes inyectadas también pueden filtrar partes de la página o tokens anti-CSRF a un atacante. Y como los filtros que eliminan las etiquetas script pero permiten otro marcado son habituales, la inyección de HTML se convierte con frecuencia en el trampolín que más tarde escala hasta un XSS completo.
La solución refleja la defensa contra el XSS: nunca coloques entrada no confiable en una página como marcado sin procesar. Codifica la salida para el contexto HTML de modo que las etiquetas se rendericen como texto visible, valida la entrada y, cuando debas aceptar contenido enriquecido, pásalo por un saneador de lista de permitidos estricta que elimine etiquetas desconocidas, manejadores de eventos y atributos peligrosos. Una Content Security Policy limita el daño de los recursos inyectados. cside opera en una capa distinta, monitorizando los scripts de terceros que carga una página: su proxy híbrido analiza cada payload, puede bloquear comportamientos maliciosos en tiempo real y conserva registros forenses que respaldan PCI DSS 6.4.3 y 11.6.1. Complementa, en lugar de reemplazar, la codificación y el saneamiento en tus propias plantillas.
Se solapan, pero no son idénticos. Ambos parten de entrada sin escapar que llega a la página. El XSS ejecuta específicamente JavaScript del atacante, mientras que la inyección de HTML abarca cualquier marcado inyectado, incluidos los casos en los que los scripts se filtran pero otras etiquetas siguen renderizándose. Todo XSS es una forma de inyección de HTML, pero no toda inyección de HTML llega a la ejecución de scripts.
Sí. Sin ningún script, un atacante puede inyectar un formulario de inicio de sesión falso para phishing en la página, desfigurar contenido, insertar enlaces o imágenes engañosos, o usar marcado colgante y CSS para exfiltrar datos como los tokens anti-CSRF. La suplantación de contenido en un dominio de confianza es convincente precisamente porque la URL es auténtica.
We answer client-side security questions every day. Bring yours.