Bloquear el XSS y subsanar vulnerabilidades
Equipo editorial de IONOS7 mins
El Cross Site Scripting o XSS es un tipo de ciberataque por el cual se buscan vulnerabilidades en una aplicación web para introducir un script dañino y atacar su propio sistema, partiendo de un contexto fiable para el usuario. Los scripts son archivos de comandos o programas escritos en lenguajes de programación −como JavaScript− que se ejecutan en el navegador web. En su versión más inocua se ejecutan ventanas emergentes y, en el peor de los casos, son utilizados por atacantes para acceder a información sensible o al equipo del usuario.
Siempre que una aplicación web transfiera datos de usuario no validados al navegador, habrá riesgo de un ataque por Cross Site Scripting o XSS, ya que este es el camino por el que los archivos dañinos van a parar al cliente o navegador. Una vez aquí, las aplicaciones infectadas manipulan scripts propios de la página tales como formularios de registro y, mientras que para el usuario todo indica que se trata de una página protegida, en realidad los datos están siendo transferidos a otro sitio sin ningún tipo de filtro.
Pero no todos los ataques de XSS tienen como objetivo robar información privada o dañar al cliente afectado. Hay scripts muy extendidos que manipulan al cliente para convertirlo en iniciador de tácticas de phishing y de ataques de malware, o que cambian el contenido de una página afectándolo negativamente. Los causantes del ataque permanecen la mayor parte de las veces en el anonimato.
Ejemplos de ataques de XSS
Para aclarar qué puede significar en concreto el Cross Site Scripting para un administrador web o para un usuario, presentamos a continuación una lista con los distintos tipos de XSS.
XSS indirecto o reflejado
Cuando abrimos una URL manipulada o rellenamos un formulario adulterado se envía el script dañiño al servidor web, que es devuelto al cliente sin ser comprobado. El código malicioso no se almacena en el servidor, sino que existe de forma temporal cuando el cliente abre la página web. Las páginas webs dinámicas y las aplicaciones de correo son especialmente vulnerables a este tipo de ataque.
Ejemplo: el atacante aloja el script en un enlace preparado que reenvía, por regla general, por correo electrónico. El código dañino se libera cuando el usuario abre el enlace, y es entonces cuando se abre una pantalla de registro en su navegador, que reproduce por ejemplo, la página de su banco online. Cuando el usuario introduce sus datos de registro, el script se encarga de reenviarlos a la dirección que el atacante ha establecido previamente.
XSS directo o persistente
En este caso, los archivos maliciosos se almacenan en el servidor web y son liberados cada vez que se accede a una página desde un navegador. Con este objetivo se eligen aquellas aplicaciones web que guardan datos de usuario en su propio servidor y los transfieren sin métodos de control o codificación. Los blogs y los foros son especialmente vulnerables para este tipo de ataques.
Ejemplo: Las intervenciones de los usuarios en un foro se guardan en una base de datos, generalmente sin un control suficiente. Los atacantes aprovechan esta oportunidad y añaden su script dañino en un post aparentemente normal. Un usuario que no sospecha nada recibe el enlace al post por correo electrónico o va a parar a él por casualidad, y en el momento en que lo abre se activa el script.
XSS basado en DOM
También llamado XSS local, en este caso el daño se provoca por medio de los scripts que están en el lado del cliente. Al abrir una página infectada, el código malicioso puede aprovechar un agujero en la seguridad para instalarse en un archivo del explorador web y ser ejecutado allí sin ninguna comprobación previa. Al contrario de lo que ocurre en las dos variantes anteriores, en este caso el servidor web no está implicado, por lo que este ataque también afecta a las páginas estáticas que implementan este tipo de lenguaje de programación.
Ejemplo: Como el XSS reflejado, el Cross Site Scripting basado en DOM requiere que el usuario abra el enlace. Cuando esto sucede, un script de la página web selecciona la variable de la URL y ejecuta el código que contiene. Es así como se pueden usurpar cookies de sesión, por ejemplo.
¿Cómo protegerse de los ataques de XSS?
Los perjuicios que puede ocasionar un ataque de Cross Site Scripting no deben ser subestimados, tanto para usuarios como para administradores de páginas web. Sin saberlo, un usuario puede arriesgar sus datos privados y actúar como cómplice de los atacantes. Los administradores web han de tener en cuenta que son responsables de los datos de sus usuarios y/o clientes. Si una web es víctima de tales ataques, los contenidos maliciosos y las caídas del servidor son causa de la pérdida de visitas de los usuarios. A la larga los buscadores reaccionan con penalizaciones y los internautas con desconfianza, lo que conlleva, en última instancia, a pérdidas económicas. Por todo esto los administradores y los usuarios deberían poner todos los medios para evitar ataques de XSS.
Medidas de prevención para internautas
Lo más sencillo para que los clientes eviten el Cross Site Scripting es desactivar JavaScript en el navegador. Si se hace eso el XSS basado en DOM, cuyo objetivo son los códigos de Java del explorador, no tiene ningún efecto, ya que no se ejecutará ningúna función maliciosa. Hay navegadores donde es posible activar Add-ons que protegen de ataques de XSS. Para Mozilla Firefox, por ejemplo, existe la extensión NoScript: su configuración estándard fija el bloqueo automático de contenidos activos tales como JavaScript, Java Applets, Adobe Flash o Microsoft Silverlight. Si se desea, se puede levantar el bloqueo temporalmente o configurar una lista blanca de páginas si estamos absolutamente seguros de que son de confianza. Y un último consejo que deberías tener siempre en cuenta en relación con los riesgos del Cross Site Scripting es que te mantengas siempre escéptico ante datos ajenos como los enlaces, que deberías siempre examinar detenidamente antes de abrir.
Acciones contra ataques de XSS para administradores web
Con el objetivo de evitar que las aplicaciones de tu web se conviertan en objeto de ataques de XSS, deberías desconfiar de cualquier dato entrante, es decir, antes de que el servidor los acepte deberían ser adecuadamente examinados. El método más seguro sería, como en el Add-On NoScript para el navegador, la creación de una whitelist o lista blanca. Mientras la capacidad de tu página permita el examen de las entradas y solo la aceptación de contenidos fiables, estarás garantizando una excelente protección contra Cross Site Scripting.
Pero también la salida de datos debería estar protegida. En este caso es necesario sustituir los problemáticos caracteres meta HTML por referencias textuales, de forma que los caracteres meta se lean como texto y los archivos potencialmente infectados no se puedan ejecutar. Para ello, la mayoría de lenguajes de programación como Perl, JavaScript o PHP contienen funciones predefinidas para la sustitución o enmascaramiento de caracteres que puedes usar sin problemas. Los Web-Application-Firewalls suponen también una efectiva defensa frente a ataques sencillos de XSS.
El Cross Site Scripting supone en muchos casos el prólogo a ataques de más gravedad, y estos se pueden evitar ya en sus inicios mediante una amplia protección del flujo entrante y saliente de datos en tu servidor web.
