Prueba de secuencias de comandos entre sitios

Cross-site Scripting (XSS) ocurre siempre que una aplicación toma datos que no son de confianza y los envía al cliente (navegador) sin validación. Esto permite a los atacantes ejecutar scripts maliciosos en el navegador de la víctima, lo que puede resultar en el secuestro de las sesiones del usuario, desfigurar sitios web o redirigir al usuario a sitios maliciosos.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Tipos de XSS

  • Stored XSS - El XSS almacenado, también conocido como XSS persistente, se produce cuando la entrada del usuario se almacena en el servidor de destino, como una base de datos / foro de mensajes / campo de comentarios, etc. Entonces la víctima puede recuperar los datos almacenados de la aplicación web.

  • Reflected XSS - El XSS reflejado, también conocido como XSS no persistente, se produce cuando una aplicación web devuelve inmediatamente la entrada del usuario en un mensaje de error / resultado de búsqueda o la entrada proporcionada por el usuario como parte de la solicitud y sin almacenar permanentemente los datos proporcionados por el usuario.

  • DOM Based XSS - DOM basado en XSS es una forma de XSS cuando la fuente de los datos está en el DOM, el receptor también está en el DOM y el flujo de datos nunca sale del navegador.

Ejemplo

La aplicación utiliza datos que no son de confianza en la construcción sin validación. Los caracteres especiales deben escaparse.

http://www.webpage.org/task/Rule1?query=try

El atacante modifica el parámetro de consulta en su navegador para:

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Las manos en

Step 1- Inicie sesión en Webgoat y navegue hasta la sección de secuencias de comandos entre sitios (XSS). Ejecutemos un ataque de Scripts de sitios cruzados almacenados (XSS). A continuación se muestra la instantánea del escenario.

Step 2- Según el escenario, inicie sesión como Tom con la contraseña 'tom' como se menciona en el escenario en sí. Haga clic en 'ver perfil' y acceda al modo de edición. Dado que Tom es el atacante, inyectemos un script Java en esos cuadros de edición.

<script> 
   alert("HACKED")
</script>

Step 3 - Tan pronto como finaliza la actualización, Tom recibe un cuadro de alerta con el mensaje "pirateado", lo que significa que la aplicación es vulnerable.

Step 4 - Ahora, según el escenario, debemos iniciar sesión como jerry (HR) y verificar si jerry se ve afectado por el script inyectado.

Step 5 - Después de iniciar sesión como Jerry, seleccione 'Tom' y haga clic en 'ver perfil' como se muestra a continuación.

Mientras ve el perfil de Tom de la cuenta de Jerry, puede obtener el mismo cuadro de mensaje.

Step 6 - Este cuadro de mensaje es solo un ejemplo, pero el atacante real puede realizar mucho más que mostrar un cuadro de mensaje.

Mecanismos preventivos

  • Los desarrolladores deben asegurarse de escapar de todos los datos que no sean de confianza basados ​​en el contexto HTML, como el cuerpo, el atributo, JavaScript, CSS o la URL en la que se colocan los datos.

  • Para aquellas aplicaciones que necesitan caracteres especiales como entrada, deben existir mecanismos de validación sólidos antes de aceptarlos como entradas válidas.