Entendiendo el Cross Site Scripting (XSS) - Parte 1/2

El XSS o “Cross-site Scripting”, es una de las vulnerabilidades que siempre se encuentran, en el TOP 10 de las más explotadas en cuanto a lo que aplicaciones web se refiere. *(Puesto número 3 en el TOP10 de OWASP).

Esta vulnerabilidad, permite a un atacante la ejecución de código del lado del cliente (navegador), siempre y cuando la aplicación web sea vulnerable a XSS.

A rasgos generales: se aprovecha de la validación incorrecta en los campos de entrada de datos de la aplicación (Ej: Formularios).

Permite la inyección de código JavaScript y similares, que además es interpretado por el servidor y por consiguiente, altera el normal funcionamiento de la aplicación.

En caso de que el ataque tenga éxito, permitirá a los atacantes robar contraseñas y otra información sensible, redirigir a los usuarios a web maliciosas, robar sesiones de usuario, suplantar identidad del usuario atacado, entre otras.

La explotación de un XSS puede causar: 

• Redirección a sitios no legítimos (páginas falsas), con la intención de engañar a la víctima.
• Secuestro de sesión de las cuentas de las víctimas, para escalar privilegios y acceder a los sistemas.
• Instalación de malware en el sistema victima.
• Ejecución de exploits en el servidor.
• Provocar un mal funcionamiento de los sistemas vulnerados.
• Denegación de Servicio (DoS).

Ejemplo básico de XSS:

XSS funciona debido a que no se validan los datos que se publican desde un campo de entrada, lo que provoca que en cualquier secuencia de comandos en el campo de entrada, con ciertas características pueda aprovechar dichas vulnerabilidades.

De esta manera, por ejemplo, un atacante podría acceder a una web vulnerable a XSS y a través de su formulario de contacto, podría preparar un ataque en el cual inyectara código en alguno de los campos de dicho formulario

Todo empieza, por ejemplo, con una página que permita insertar comentarios o contenido, por parte de los usuarios. Esto puede producirse en cualquier tipo de formulario, comentarios de contenido, etc.

Si en cualquiera de estos cuadros de texto, un atacante, en vez de introducir los datos que pida el formulario, introdujera: <script>alert('Comentario')</script>, (lenguaje en JavaScript) y al enviar saltara un pop-up, nos encontraríamos ante una aplicación vulnerable a XSS. 

Tipos de XSS:

Hay que tener en cuenta, que este tipo de vulnerabilidad puede ser darse de diferentes formas:

• XSS Reflejado.
• XSS Almacenado.
• XSS Basado en DOM.

A continuación, haré una breve explicación de cada una:

• XSS Reflejado: También conocido como indirecto o no persistente, es el más habitual de los XSS. Es temporal, ya que solo se ejecuta al enviar la petición una vez a nivel navegador. Bastante común en páginas web dinámicas y aplicaciones de correo. Las posibles consecuencias: Robo de cookies, secuestro de navegador, phising, cambio del contenido y estructura de la aplicación web, instalación de software malicioso en el sistema. 

• Almacenado: También conocido como directo o persistente, perdura en el servidor, ya que al ejecutarlo por primera vez se almacena en la base de datos de la aplicación web. Cada vez que se cargue la página web, se ejecutará nuevamente y se mostrará la inyección a los usuarios de la misma. Las posibles consecuencias: Además de las indicadas en el XSS Reflejado, captura de información de las aplicaciones, defacement de app, escaneo de puertos de las víctimas, ejecución de exploits, denegación de servicio. 

• Basado en DOM: Es un XSS local y persistente, que esta basado en modificar el entorno DOM* del navegador, debido a su mal uso. Este tipo de XSS se ejecuta del lado del cliente, afecta a páginas estáticas, siendo un ejemplo de elementos vulnerables: document.location / document.URL / etc. Las consecuencias son similares a las presentes en los XSS reflejado y almacenado. *(Para los que no estén al día sobre DOM, nos referimos al Modelo de Objetos del Documento (DOM), el cual es una interfaz de programación de aplicaciones (API) para documentos validos HTML. Define la estructura lógica de los documentos y el modo en que se accede y manipulan).

¿Como identificar XSS?:

Para identificar una vulnerabilidad de "cross site" en primera instancia, debemos de pensar en algunas de las causas que producen que esta vulnerabilidad este presente en una aplicación web, como son un mal filtrado de datos o no validación de entradas de datos en la aplicación (permite la introducción de todo tipo de valores, aunque no sea necesario).

Para ello, en apartados de la web destinados a la entrada de datos, como son formularios, paneles de acceso e identificación de usuarios, etc., se puede probar la introducción de comandos, como: <script>alert('XSS')</script>.

También se puede probar simplemente si la aplicación valida en estos campos de entrada, la introducción de caracteres especiales, como: /, < >, ".

Para asegurar del todo, que no se puedan ejecutar script en estos campos de entrada de datos, no deberían de permitirse la introducción de ciertos tipos de palabras, como: script, alert, src, etc.


¿Contramedidas?:

De la mano del punto anterior, vendrían las contramedidas y aspectos a tener en cuenta para evitar ser vulnerables a XSS, ya que los puntos que identifican un XSS son los que se deben evitar.
Para ello, se deben de tomar algunas como las siguientes medidas:

• Validación de datos (en todos los campos de entrada, tanto del lado del cliente como del servidor). Solo se permitirán valores esperados y adecuados a lo que se está pidiendo (formato, longitud, etc.). Por ejemplo, no tiene sentido que en un campo de un formulario, en el que se esta pidiendo el nombre o apellido de una persona, se puedan introducir números o caracteres.
• Sanitización de datos en los campos de entrada (Solo se permitirá texto plano, a nivel de que no se interprete o ejecute ningún tipo de comando).
• Creación de listas (blancas y negras) para restringir los datos esperados. De esta manera, palabras como "script", estarán totalmente prohibidas y no serán aceptadas.
• Evitar que el sistema ejecute código, al menos el proveniente de sitios concretos, como formularios. 
• Hacer que las cadenas de entrada de datos, se conviertan en alfanuméricas, al igual que los datos introducidos por los usuarios se conviertan a sus equivalentes en HTML.

Todas estas medidas pueden tomarse desde el lado del servidor.

Hasta ahora hemos hablado de las medidas a tomar desde el lado del servidor, a la hora de securizar la aplicación, si queremos mantenernos seguros si nos encontramos en el lado del usuario, algunas de las cosas que tenemos que observar son las siguientes:

• Como siempre y como una de las normas fundamentales en cuanto a mantener la seguridad al máximo se refiere, es primordial tener actualizado a la versión más actual todo el software del equipo: aplicaciones, sistema operativo, navegadores, etc.
• Ante todo ser conscientes de lo que hacemos y de como navegamos, ojo con enlaces sospechosos, urls acortadas, links que no sabemos donde nos redirigen, etc.
• Algo muy importante y que en una primera instancia no encontramos entre los consejos habituales, es que debemos de ser muy conscientes del estado de nuestro navegador, como lo tenemos configurado, etc. Por ejemplo, debemos de tener mucho cuidado con que complementos tenemos instalados y evitar o al menos controlar los que permitan la ejecución de scripts de manera automática.

• Aunque parece evidente, siempre hay que nombrar que tener una solución de seguridad instalada en el equipo, que evite la ejecución de malware, siempre será un punto a nuestro favor.