Bloquear el XSS y subsanar vu­l­ne­ra­bi­li­da­des

Para aclarar qué puede si­g­ni­fi­car en concreto el Cross Site Scripting para un ad­mi­ni­s­tra­dor web o para un usuario, pre­se­n­ta­mos a co­n­ti­nua­ción una lista con los distintos tipos de XSS.

XSS indirecto o reflejado

Cuando abrimos una URL ma­ni­pu­la­da o re­lle­na­mos un fo­r­mu­la­rio adu­l­te­ra­do se envía el script dañiño al servidor web, que es devuelto al cliente sin ser co­m­pro­ba­do. 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 apli­ca­cio­nes de correo son es­pe­cia­l­me­n­te vu­l­ne­ra­bles a este tipo de ataque.

Ejemplo: el atacante aloja el script en un enlace preparado que reenvía, por regla general, por correo ele­c­tró­ni­co. 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 re­en­viar­los a la dirección que el atacante ha es­ta­ble­ci­do pre­via­me­n­te.

XSS directo o pe­r­si­s­te­n­te

En este caso, los archivos ma­li­cio­sos 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 apli­ca­cio­nes web que guardan datos de usuario en su propio servidor y los tra­n­s­fie­ren sin métodos de control o co­di­fi­ca­ción. Los blogs y los foros son es­pe­cia­l­me­n­te vu­l­ne­ra­bles para este tipo de ataques.

Ejemplo: Las in­te­r­ve­n­cio­nes de los usuarios en un foro se guardan en una base de datos, ge­ne­ra­l­me­n­te sin un control su­fi­cie­n­te. Los atacantes apro­ve­chan esta opo­r­tu­ni­dad y añaden su script dañino en un post apa­re­n­te­me­n­te normal. Un usuario que no sospecha nada recibe el enlace al post por correo ele­c­tró­ni­co o va a parar a él por ca­sua­li­dad, y en el momento en que lo abre se activa el script.

Los pe­r­jui­cios que puede ocasionar un ataque de Cross Site Scripting no deben ser su­b­e­s­ti­ma­dos, tanto para usuarios como para ad­mi­ni­s­tra­do­res de páginas web. Sin saberlo, un usuario puede arriesgar sus datos privados y actúar como cómplice de los atacantes. Los ad­mi­ni­s­tra­do­res web han de tener en cuenta que son re­s­po­n­sa­bles de los datos de sus usuarios y/o clientes. Si una web es víctima de tales ataques, los co­n­te­ni­dos ma­li­cio­sos y las caídas del servidor son causa de la pérdida de visitas de los usuarios. A la larga los bu­s­ca­do­res reac­cio­nan con pe­na­li­za­cio­nes y los in­te­r­nau­tas con de­s­co­n­fia­n­za, lo que conlleva, en última instancia, a pérdidas eco­nó­mi­cas. Por todo esto los ad­mi­ni­s­tra­do­res y los usuarios deberían poner todos los medios para evitar ataques de XSS.

Medidas de pre­ve­n­ción para in­te­r­nau­tas

Lo más sencillo para que los clientes eviten el Cross Site Scripting es des­ac­ti­var Ja­va­S­cri­pt en el navegador. Si se hace eso el XSS basado en DOM, cuyo objetivo son los códigos de Java del ex­plo­ra­dor, no tiene ningún efecto, ya que no se ejecutará ningúna función maliciosa. Hay na­ve­ga­do­res donde es posible activar Add-ons que protegen de ataques de XSS. Para Mozilla Firefox, por ejemplo, existe la extensión NoScript: su co­n­fi­gu­ra­ción estándard fija el bloqueo au­to­má­ti­co de co­n­te­ni­dos activos tales como Ja­va­S­cri­pt, Java Applets, Adobe Flash o Microsoft Si­l­ve­r­li­ght. Si se desea, se puede levantar el bloqueo te­m­po­ra­l­me­n­te o co­n­fi­gu­rar una lista blanca de páginas si estamos ab­so­lu­ta­me­n­te 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 de­te­ni­da­me­n­te antes de abrir.

Acciones contra ataques de XSS para ad­mi­ni­s­tra­do­res web

Con el objetivo de evitar que las apli­ca­cio­nes de tu web se co­n­vie­r­tan en objeto de ataques de XSS, deberías de­s­co­n­fiar de cualquier dato entrante, es decir, antes de que el servidor los acepte deberían ser ade­cua­da­me­n­te exa­mi­na­dos. 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 ace­p­ta­ción de co­n­te­ni­dos fiables, estarás ga­ra­n­ti­za­n­do una excelente pro­te­c­ción contra Cross Site Scripting.

Pero también la salida de datos debería estar protegida. En este caso es necesario sustituir los pro­ble­má­ti­cos ca­ra­c­te­res meta HTML por re­fe­re­n­cias textuales, de forma que los ca­ra­c­te­res meta se lean como texto y los archivos po­te­n­cia­l­me­n­te in­fe­c­ta­dos no se puedan ejecutar. Para ello, la mayoría de lenguajes de pro­gra­ma­ción como Perl, Ja­va­S­cri­pt o PHP contienen funciones pre­de­fi­ni­das para la su­s­ti­tu­ción o en­ma­s­ca­ra­mie­n­to de ca­ra­c­te­res que puedes usar sin problemas. Los Web-Ap­pli­ca­tion-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 pro­te­c­ción del flujo entrante y saliente de datos en tu servidor web.