2009-09-05 7 views
5

Él chicos,XSS Cross-protocolo con los puertos de servicio no estándar

acabo de leer this post acerca de maneras muy desagradables (y fresco al mismo tiempo) para llevar a cabo XSS. Sin embargo, todavía hay algo poco claro para mí.

Entiendo el concepto completo del ataque, sin embargo, no veo cómo esto puede ser potencialmente explotado. El atributo "acción" dentro del formulario debe apuntar a un servidor ftp (o cualquier otro servidor que refleje la entrada), pero este nunca es el caso.

De modo que a menos que tenga otro agujero XSS para inyectar tal forma, esta vulnerabilidad no puede ser explotada. Mi pregunta es si mi conclusión de que no puede ser explotada es cierta o si me falta algo.

+0

Nadie tiene una respuesta? – Henri

Respuesta

3

Esto se puede aprovechar de la siguiente manera.

  • MrCrim quiere robar el nombre de usuario de una persona que utiliza victim.net
  • MrCrim da cuenta de que victim.net se está ejecutando un servidor FTP en un puerto inusual
  • MrCrim pone un formulario en su propio sitio, evil.com
  • El formulario contiene los "comandos ftp" en los elementos del formulario y su acción posterior es para victim.net
  • MrCrim escribe un script JS que roba document.cookie de un sitio y aloja ese script en a. archivo js en evil.com. Probablemente funcione incluyendo la cadena de cookies como parte de una URL fuente de imagen que se solicita desde evil.com
  • Uno de los "comandos ftp" en la forma de MrCrim está diseñado para escribir un pequeño bit de JS que ejecuta el robo de cookies de MrCrim script
  • MrCrim tienta a las personas a mirar a evil.com publicando enlaces en foros y enviando spam.
  • UnsuspectingUser sigue un enlace publicado en su foro favorito y aterriza en evil.com. Publica el formulario, sin saber de sus malas y astutas intenciones
  • ¡UnsuspectingUser está ahora en victim.net y Bam! el JS "inyectado" por el servidor FTP se ejecuta y la cookie de UnsuspectingUser para victim.net se envía a evil.com
  • ¡Ganancia! :-)
+0

Ahhh, ahora lo entiendo. Había confundido el concepto de referencia y la misma política de origen. Estaba pensando que el referer no estaba en el mismo dominio que el servidor ftp. Pero ahora lo entiendo ¡Gracias! – Henri

0

Supongo que su argumento es que nadie ejecuta el servidor FTP en el mismo host que el servidor HTTP. Estás en lo correcto si esta suposición es verdadera. No puede ser explotado si usted está seguro de que no tiene otros puertos abiertos.

Para explotar este agujero en IE, el host debe tener otros servicios en ejecución y los números de puerto no deben ser estándar. Esto es realmente raro. Muchos sitios tendrán FTP en el mismo host pero normalmente usan el número de puerto estándar (21). Sin embargo, esto puede suceder sin embargo. Mi empresa de hosting ejecuta un servidor FTP en varios puertos (uno no es estándar) en el mismo host donde se publica mi página web y esa es una forma alternativa de actualizar las páginas si la herramienta de autoría no admite WebDAV.

0
  • Ataque alojada en un servidor diferente,
  • servidor FTP deben alojada en el servidor víctima
  • Desde el ataque consigue su respuesta desde el servidor víctima, ahora la página de atacante puede leer las cookies. Porque ahora el código de los atacantes se refleja en el contexto del dominio del objetivo.

Eso es todo.

So no, no necesita otra vulnerabilidad, un servidor FTP o un servidor similar con puerto de acceso público es suficiente para ser vulnerable.

Cuestiones relacionadas