Hace unos días contábamos en este mismo blog qué era y cómo funcionaba, paso a paso, un ataque de SQL Injection. Vimos que se trataba de una forma «low cost» de que cualquiera desde Internet pudiera ejecutar órdenes en una base de datos, aprovechando un fallo de programación en la página web detrás de la que se encuentra dicha base de datos.
Hoy hablaremos de otro tipo de ataque, el denominado «Cross Site Scripting» o XSS por sus siglas en inglés, que tiene el mismo origen que el SQL Injection. De hecho, es habitual que si un sitio web es susceptible de ser atacado por una de estas dos modalidades, también lo sea por la otra.
Ambas son las dos caras de una misma moneda: el precio que se paga por haber contratado un pésimo programador para que nos construya la página web de la empresa.
La víctima del XSS
Sin embargo, la víctima cambia en una y en otra cara de la moneda. Si con el SQL Injection, el oscuro objeto de deseo del aprendiz de hacker del que hablábamos el otro día, era la base de datos, normalmente información propiedad de la empresa que gestiona la página web.
En cambio, con el XSS del que hablaremos hoy, el hacker ataca a otros usuarios que se conectan a dicha página web, y los ataca en busca de varias cosas: secuestrarles la sesión, robarles la contraseña o cualquier otra información que considere de interés.
También, en casos más sofisticados, puede redirigirle a una página fraudulenta o incluso puede intentar instalar software arbitrario en el PC de la víctima, como por ejemplo un espía del teclado y del ratón, que recolectará todo lo que la víctima vaya tecleando y haciendo clic.
Cómo funciona el 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.
¿Cómo saber si un sitio web tiene esta vulnerabilidad?
Si en un sitio que ofrece búsquedas por palabras clave, en lugar de usar ese campo para buscar, escribimos lo siguiente: <script type = ‘text / javascript’> alert (‘soy vulnerable a XSS reflejado’); </ script> , le damos a buscar y, … voilà, entonces aparece un «pop up» con el mensaje «soy vulnerable a XSS reflejado», ¡bingo!: este sitio tiene la vulnerabilidad XSS reflejado.
Y ahora, sé lo que estás pensando querido lector, si esta página del blog del IMF tiene este tipo de vulnerabilidad. Pues solo hay una forma de comprobarlo… Ah!, pero si la encuentras, por favor, compórtate como un hacker del lado luminoso de la fuerza y avisa aquí.
Pero saber que un sitio web es vulnerable a este tipo de ataque no basta. A continuación, el hacker debe confeccionar una URL, que incorpore ciertas instrucciones de una forma astuta, y que no vamos a contar aquí pero que sí explicamos a nuestros alumnos del Máster de Ciberseguridad, e incorporarla como un enlace en un correo electrónico. Entonces puede hacérsela llegar a un grupo de usuarios de dicha web de la forma que sea, por correo o como una colaboración en una red social por ejemplo.
¿Cómo podemos defendernos?
Existen varias líneas de defensa efectivas para prevenir y mitigar los ataques XSS.
La primera línea de defensa debe ser siempre el programador de las aplicaciones web, que debe filtrar las entradas de usuario para evitar que se introduzcan secuencias de caracteres escritas en HTML o JavaScript, usando funciones como htmlspecialchars(), htmlentities() y strip_tags() del lenguaje PHP.
El problema es que los hackers se las ingenian también a engañar a estos filtros, si no están bien dispuestos, y han desarrollado técnicas para sobrepasarlos.
Después del programador, en la siguiente línea tendremos al administrador del servidor web. Implantar y configurar un cortafuegos de aplicación web (WAF) puede jugar un papel crucial para filtrar ataques XSS que hayan pasado la primera línea de defensa. Como saben nuestros alumnos del Máster de Ciberseguridad, con unas reglas de seguridad apropiadas basadas en firmas, complementadas con otras de tipo heurístico, un WAF puede compensar la ausencia de comprobaciones en las entradas y simplemente bloquear todas aquellas solicitudes que parezcan anormales.
Con las tecnologías WAF cabe señalar que, a diferencia de un ataque XSS persistente, donde lo que se bloquea son las solicitudes maliciosas del atacante, en un ataque XSS reflejado, las que se bloquean son las solicitudes de los usuarios potenciales víctimas del ataque.
La tercera línea de defensa está en el lado del usuario. Además del eterno consejo de mantener actualizados nuestros navegadores, «plugins» y otros programas como el Flash Player, la precaución es la mejor manera de evitar caer en un XSS.
Específicamente, para el caso del XSS reflejado esto significa no hacer «click» en enlaces sospechosos que pueden contener código malicioso. Los enlaces sospechosos pueden venir en:
- Correos electrónicos de remitentes desconocidos.
- Los comentarios de los usuarios en los foros de un sitio web.
- «Post» en redes sociales de usuarios desconocidos.
Conectar un servidor web a Internet no consiste solo en «enchufarlo», y navegar no siempre es algo plácido… puede haber cocodrilos bajo el agua.
Manuel Carpio, tutor del Máster de Ciberseguridad de IMF Business School
Formación Relacionada
Muy interesante el artículo