Test de seguridad usando secuencias de comandos de Cross-site Scripting (XSS).

Cross-site Scripting (XSS) ocurre cada vez 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 secuencias de comandos maliciosas en el navegador de la víctima, lo que puede provocar el secuestro de sesiones de 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

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

• XSS reflejado : el XSS reflejado, también conocido como XSS no persistente, ocurre 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. .

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

Ejemplo

La aplicación utiliza datos no confiables en la construcción sin validación. Los caracteres especiales deben ser escapados.

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

Paso 1 : inicie sesión en Webgoat y navegue hasta la sección Cross-site scripting (XSS). Ejecutemos un ataque Stored Cross-site Scripting (XSS). A continuación se muestra la instantánea del escenario.

Paso 2 : según el escenario, iniciemos sesión como Tom con la contraseña 'tom' como se menciona en el escenario mismo. Haga clic en 'ver perfil' y acceda al modo de edición. Dado que tom es el atacante, inyectemos Java script en esos cuadros de edición.

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

Paso 3 : tan pronto como finaliza la actualización, Tom recibe un cuadro de alerta con el mensaje "hackeado", lo que significa que la aplicación es vulnerable.

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

Paso 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 desde la cuenta de Jerry, puede obtener el mismo cuadro de mensaje.

Paso 6 : este cuadro de mensaje es solo un ejemplo, pero el atacante real puede hacer mucho más que mostrar un cuadro de mensaje.

Mecanismos Preventivos

• Los desarrolladores deben asegurarse de escapar de todos los datos que no son de confianza en función del 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, debe haber mecanismos de validación sólidos antes de aceptarlos como entradas válidas.

Fuente: https://www.tutorialspoint.com/security_testing/testing_cross_site_scripting.htm