La suplantación de contenido (también conocida como inyección de contenido) es una de las vulnerabilidades de seguridad web más comunes. Permite al usuario final de la aplicación web vulnerable suplantar o modificar el contenido real de la página web. El usuario puede usar las lagunas de seguridad en el sitio web para inyectar el contenido que desea en el sitio web de destino. Cuando una aplicación no maneja correctamente los datos proporcionados por el usuario, un atacante puede proporcionar contenido a una aplicación web, generalmente a través de un valor de parámetro, que se refleja al usuario.
Hay dos tipos básicos de inyección posibles aquí:
- Inyección de texto
- Inyección HTML
Inyección de texto:
La inyección de texto es una subcategoría en la que el usuario podrá inyectar solo texto sin formato en la página. En otras palabras, no es posible inyectar contenido JavaScript ejecutable, comandos de shell o contenido HTML. En la mayoría de los casos, el usuario podría cambiar parte del contenido de texto que ya está en el sitio web.
Inyectar contenido de texto
En algunos casos, el contenido real que se va a mostrar en la interfaz de usuario se pasa a través de parámetros de solicitud. Por ejemplo, un formulario de inicio de sesión simple pasará la solicitud como se indica a continuación,
https://www.testsite.com/loginAction?userName=test123&password=test123/
Puede tener una validación del lado del cliente para verificar si el nombre de usuario y/o la contraseña están vacíos o no de la forma esperada y, en función de eso, puede mostrar un mensaje en la interfaz de usuario, que indica que estos campos no pueden estar vacíos. El problema ocurre cuando este mensaje se agrega como un parámetro de solicitud como este,
https://www.testsite.com/loginAction?errorMsg=PasswordEmpty
Una vez que el usuario vea esta solicitud, podrá modificar el mensaje a su gusto y se le mostrará en pantalla. Este tipo de inyección se puede realizar en cualquier parte del sitio si se pasa un mensaje a través de parámetros de solicitud. Cuanto mayor sea la visibilidad del texto inyectado, mayor será la posibilidad de que el sitio se vea afectado cuando alguien usa la laguna.
El sitio puede ser un sitio web creíble y el usuario puede agregar contenido ofensivo y difundir el enlace y para la víctima, parece que el propietario del sitio ha publicado contenido ofensivo.
Inyección HTML:
La inyección de HTML es similar a la inyección de texto y, como su nombre indica, permite inyectar contenido HTML. Esta es una clase relativamente grave de vulnerabilidad de falsificación de contenido, ya que es posible hacer que el contenido ofensivo sea más visible con HTML que con texto sin formato.
Inyectar contenido HTML
Algunos sitios también pasan contenido HTML en los parámetros de solicitud. Por ejemplo, en ventanas emergentes o banners de sitios, los sitios pasan el contenido HTML real en parámetros y lo colocan dentro de una divetiqueta como,
https://www.testsite.com/setAdContent?divMessage=<h1>ClickHere</h1>
Y el valor del parámetro divMessage se crea en el sitio dentro de un div y se representa como HTML sin filtrar. Esta es una vulnerabilidad grave y es obvio que si se explota, podría reducir la credibilidad del sitio en mayor medida.
Es posible modificarlo como,
https://www.testsite.com/setAdContent?divMessage=<marquee><h1>Don't Use this site</h1><marquee>
y su propio sitio tendrá un mensaje que se desplaza diciendo que no lo use.
XSS a través de inyección de HTML
Esto podría ser aún más grave cuando el mensaje de los parámetros se representa directamente sin ningún tipo de codificación/filtrado. En ese caso, conduce a una vulnerabilidad aún más grave de XSS, también conocido como secuencias de comandos entre sitios, donde el usuario podría inyectar JavaScript ejecutable que compromete completamente la seguridad del sitio web.
Será algo así,
https://www.testsite.com/setAdContent?divMessage=<body onload=javascript:alert(1)>>
y su sitio es propenso a secuencias de comandos entre sitios.
Medidas de seguridad:
- Nunca construya y envíe mensajes de error a través de parámetros de solicitud.
- Preferir usar mensajes predefinidos en un archivo de propiedades.
- Evite pasar contenido HTML a través de parámetros de solicitud.
- En caso de que sea necesario pasar cualquier contenido HTML, codifique/filtre antes de representarlo como HTML.
- Pase las claves de mensajes internos para obtener valores de mensajes predefinidos o algunas identificaciones únicas para identificar el contenido que se mostrará