Bloquear el XSS y subsanar vulnerabilidades

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.

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.