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 falsificar o modificar el contenido real de la página web.
Requerimientos:
- Dominio – Un dominio para realizar las pruebas
- Programación – Conocimientos altos de programación
Resposabilidad:
En este tutorías utilizaremos técnicas de hacking, con el único fin de aprendizaje. No promovemos su utilización ni con fines lucrativos o incorrectos. No nos hacemos responsables de cualquier daño o menoscabo que pueda generar en los sistemas utilizados. La responsabilidad es absoluta del usuario de este tutorial.
Conocimientos:
- Linux – No aplica
- Programación – Alto
- Kali Linux – No aplica
- Windows – No aplica
- Redes – Bajo
Nivel general del Tutorial: Medio
Ideal para: Ingenieros de sistemas, Ingenieros de seguridad, Pentesters
El usuario puede utilizar las brechas de seguridad de la página web para inyectar el contenido que desee en el sitio web de destino. Cuando una aplicación no maneja adecuadamente los datos suministrados por el usuario, un atacante puede suministrar contenido a una aplicación web, normalmente a través de un valor de parámetro, que se refleja de vuelta al usuario.
Hay dos tipos básicos de inyección posibles aquí:
- Text Injection
- HTML Injection
Text Injection
La inyección de texto es una subcategoría en la que el usuario podrá inyectar sólo texto plano en la página. En otras palabras, no es posible inyectar contenido ejecutable de JavaScript, comandos de shell o contenido HTML. El usuario, en la mayoría de los casos, sólo podrá cambiar parte del contenido de texto que ya está en el sitio web.
Inyección de 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 simple formulario de acceso pasará la solicitud como se indica a continuación,
https://www.testsite.com/loginAction?userName=test123&password=test123/
Usted puede tener una validación del lado del cliente para comprobar si el nombre de usuario y/o la contraseña están vacíos o no de la forma esperada y en base a eso puede mostrar un mensaje en la UI, que estos campos no pueden estar vacíos. El problema ocurre cuando este mensaje se adjunta como un parámetro de solicitud como este,
https://www.testsite.com/loginAction?errorMsg=PasswordEmpty
Una vez que el usuario ve esta la petición, puede modificar el mensaje como desee y que se mostrará en la pantalla. Este tipo de inyección puede realizarse 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 utilice la brecha.
El sitio podría ser un sitio web creíble y el usuario podría añadir contenido ofensivo y difundir el enlace y para la víctima, parece que el propietario del sitio ha publicado contenido ofensivo.
HTML Injection
La inyección HTML es similar a la inyección de texto y, como su nombre indica, permite inyectar contenido HTML. Se trata de una clase de vulnerabilidad de suplantación de contenido relativamente grave, ya que es posible hacer que el contenido ofensivo sea más visible con HTML que utilizando texto plano.
Inyección de contenido HTML
Algunos sitios pasan contenido HTML también en los parámetros de solicitud. Por ejemplo, en las ventanas emergentes o los banners del sitio, los sitios pasan el contenido HTML real en los parámetros y hacen que se encuentre dentro de una etiqueta div como,
https://www.testsite.com/setAdContent?divMessage=<h1>ClickHere</h1>
Y el valor del parámetro divMessage se hace al sitio dentro de un div y se renderiza como HTML sin filtrar. Esta es una vulnerabilidad grave y es obvio que si se explota, podría hacer caer la credibilidad del sitio en mayor medida.
Se puede modificar como,
https://www.testsite.com/setAdContent?divMessage=<marquee><h1>Don't Use this site</h1><marquee>
y su propio sitio tendrá un mensaje de desplazamiento diciendo que no lo use.
XSS vía inyección de HTML
Esto podría ser aún más grave cuando el mensaje de los parámetros se renderiza directamente sin ninguna codificación/filtrado. En ese caso, conduce a una vulnerabilidad aún más grave de XSS aka Cross-site scripting donde el usuario podría ser capaz de inyectar JavaScript ejecutable que compromete la seguridad del sitio web por completo.
Será algo así,
https://www.testsite.com/setAdContent?divMessage=<body onload=javascript:alert(1)>>
y su sitio es propenso al cross site scripting.
Medidas de seguridad:
- Nunca construya y envíe mensajes de error a través de parámetros de solicitud.
- Prefiera usar mensajes predefinidos en un archivo de propiedades.
- Evite pasar contenido HTML a través de los parámetros de la petición.
- En caso de que sea necesario pasar algún contenido HTML, haga la codificación/filtrado antes de renderizarlo como HTML
- Pasar claves de mensajes internos para obtener valores de mensajes predefinidos o algunos ids únicos para identificar el contenido a mostrar
