Funcionamiento de Cross Site Scripting

Pero, ¿cómo funciona en realidad un XSS?.  Existen dos modalidades, denominadas directa o
persistente e indirecta o reflejada.

En ambos casos, el atacante malicioso inyecta código sobre algún campo de entrada de

datos que ofrezca la página web, bien sea este la típica cajita con el icono de la lupa para
búsqueda de palabras clave, un recuadro de espacio de participación en un foro, o un
formulario de recogida de datos.

La inyección de código, al igual que en el caso del SQL, consiste en intercalar pequeños
programas o comandos en medio del texto que se escribe en ese recuadro, pero ahora no será
el servidor web, ni el sistema de gestión de la base de datos quienes ejecutarán ese código,
como en el caso del SQL Injection, sino que ahora con la vulnerabilidad XSS quien ejecutará ese
código es el navegador del usuario víctima.

Dependiendo de las habilidades de nuestro aprendiz de hacker y sus conocimientos en

desarrollo de aplicaciones web, cuanta más experiencia y conceptos teóricos y prácticos
domine en estos campos, mejores serán los scripts que desarrolle y las posibilidades de
explotar vulnerabilidades XSS.

Tipos de vulnerabilidad XSS

Básicamente existen dos modalidades de vulnerabilidad XSS, muy parecidas entre sí, y que se
conocen como «reflejada» y «persistente».

Cross Site Scripting persistente

Si el código que hemos insertado se queda almacenado en el servidor, por ejemplo formando
parte de una contribución en un foro, el ataque se dice que es persistente. Cualquier usuario
que entre a leer dicha contribución leerá el texto inocente pero probablemente no así el código
inyectado, que sin embargo sí será interpretado por el navegador del visitante, ejecutando las
instrucciones que el hacker haya definido.

Estas acciones pueden ser variadas, y dependerá del tipo de navegador, de sus vulnerabilidades
inherentes, así como también de las de otros programas que tenga instalados, el Adobe Flash
Player por ejemplo, que se ejecuten como el hacker tiene previsto. Para él es por tanto una
ruleta de la suerte. No puede predecir el usuario que va a caer en la trampa.

Cross Site Scripting reflejado

Pero si el código que insertamos no se queda almacenado en la web, sino que va embebido
dentro de un enlace que se hace llegar de algún modo a la víctima para que pinche en él, se dice
que este tipo de ataque es reflejado. Se llama así porque, si finalmente la víctima pincha en el
enlace, el navegador le llevará a la página en cuestión, que normalmente es un sitio legal donde
el usuario tiene cuenta abierta, y a continuación ejecutará el código embebido, el cual intentará
robarle la «cookie» de la sesión, o los datos que introduzca en el formulario, o incluso podrá
desencadenar acciones más sofisticadas en su PC. Pero la característica diferencial con el
anterior ataque es que en este caso en el servidor web no queda almacenado nada.
Por eso, este tipo de ataque es más difícil de detectar y de perseguir. Además, esa URL
construida a propósito, puede ofuscarse para que no levante sospechas entre sus potenciales
víctimas. Otra característica diferencial es que ahora, este ataque sí que puede estar dirigido
contra un usuario concreto, al que se quiere suplantar en el acceso al servidor.