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.