Peligros del Cross-Site Scripting
Bienvenidos a un número más de esta revista. En este artículo se hablará sobre una vulnerabilidad más que conocida, el Cross-Site Scripting (XSS), se hablará también del uso que se le esta dando actualmente. Porque aunque no lo parezca puede llegar a tener gran importancia, de hecho, si se aprovecha correctamente puede llegar a ser bastante peligroso y perjudicial para el usuario.
Antes de empezar hay que decir que este error se basa principalmente en la ingenuidad de la víctima, así como la facilidad que tienen los usuarios de “aceptar” cada mensaje que proviene del navegador sin leerlo si quiera. Aunque también es posible realizar el ataque XSS sin que el cliente intervenga directamente, es decir, de manera invisible. Así que para empezar a introducir el tema se va a hablar de la herramienta predominante en los clientes de Internet, el navegador web.
Para el tema que importa ahora, XSS; se debe hablar de la interacción que se puede llevar a cabo desde el navegador. Según el site que se esta visitando, se dispone de un tipo de interacción u otro, dependiendo de la tecnología web usada. Por ejemplo, una web estática sólo proporciona información, y un usuario no podrá realizar muchas más acciones que pulsar en un link directo, ya que todo ocurre en el propio navegador, en cambió en una web dinámica se puede interaccionar con el servidor de una manera mucho más directa, por ejemplo, realizando peticiones con parámetros.
Un pequeño listado de las tecnologías más “típicas” que soportan los navegadores actuales podrían ser: HTML, JavaScript, CSS... Cada una tiene su propia funcionalidad, además es posible añadir soporte para otro tipo de elementos, como Flash o Java, utilizando para ello plugins externos. Para poder ver la totalidad de tecnologías soportadas por los navegadores más usados, como Firefox e Internet Explorer, basta con acceder a las siguientes url respectivamente:
Con todo esto se quiere decir que el navegador puede realizar muchas funciones, algunas de las cuales pueden llegar a comprometer nuestra seguridad si se usan con malas intenciones. Algunos recordareis esos dialers de las páginas para adultos que se instalaban solos sin conocimiento del usuario. Es por eso que hay que dedicar especial atención a los mensajes procedentes de las visitas por Internet y aceptar solamente aquellos de los que se esté realmente seguro y provengan de una fuente de confianza.
Según la inyección, el problema es más o menos serio, en este artículo se hablará de la inyección de código HTML y Javasciprt, ya que son lenguajes que afectan directamente al cliente. También se podría hablar de inyecciones en el servidor, pero entonces sería otro tipo de problema: SQL Injection, PHP Injection, IMAP/SMTP Injection, LDAP Injection, SSI Injection.... Y sería una explicación demasiado extensa.
El XSS no es más que una inyección HTML o Javascript, como ya se ha dicho anteriormente. Veamos un simple código a modo de ejemplo, meramente conceptual y que no funciona:
Supongamos que la sentencia en la tercera línea se encarga de imprimir por pantalla el valor de la variable “var1” pasada por GET. Si se hiciera la siguiente llamada:
La respuesta sería una web en blanco con la palabra “prueba” escrita al inicio (ver imagen1). Nada peligroso por el momento. Veamos ahora otro tipo de comportamiento. Añadiendo etiquetas HTML al valor de la variable podemos modificar el código resultante. Por ejemplo, pasando la cadena: 'user:<input type="text" length="25" /><br />pass:<input type="pass" length="25" />' directamente, es decir, con la llamada:
El resultado será el que se puede observar en la imagen2. Se puede ver que la salida es muy distinta a la anterior 'una web en blanco con la palabra “prueba”'. En este caso lo que ha ocurrido es que el navegador ha interpretado los caracteres que hemos inyectado. Dicho de otra manera, es posible inyectar cualquier código interpretable por el navegador y hacer que este se comporte en consecuencia.
Para realizar este ataque bastaría con imitar un formulario de login en la web vulnerable y enviar los datos a un servidor privado controlado por el atacante. Después, para infectar al usuario bastaría con postear el link o enviárselo por correo (spam). El esqueleto del código inyectado podría ser parecido al utilizado en el primer ejemplo y el resultado análogo al de la imagen2, sólo que con la estética de la web vulnerable que se pretenda suplantar.
Los programas descargados de esta manera pueden ser tanto un fichero que luego es necesario que el usuario lo ejecute confiando con el origen en una fuente de confianza, a modo de actualización por ejemplo, o bien un applet Java o ActiveX. Que se encargará de hacer todas las acciones necesarias para la infección. Así que hay que asegurarse siempre bien de dónde se están bajando los ficheros y validar la autoría del remitente.
El objetivo de XSS Shell es controlar el navegador de la víctima, mientras que XSS Tunnel llega un poco más allá y es capaz de crear un canal de comunicación entre el atacante y la red, pasando por la víctima o, lo que es lo mismo, un proxy. Ambas se sirven de la misma técnica, inyectar código javascript para infectar el navegador al mismo tiempo que regeneran la web vulnerable a ataques de tipo XSS. De esta manera se mantiene a la víctima en un entorno virtual controlado, aunque este echo supone alguna que otra restricción. Por ejemplo, si pensamos en los navegadores actuales con pestañas, en este caso solo se infectaría la pestaña que hubiera accedido a la web maliciosa, quedando todas las demás fuera del alcance de la infección.
La primera pregunta que viene a la cabeza es el funcionamiento de la comunicación entre el atacante y la víctima para poder crear el canal de comunicación, ya que, a priori, una conexión directa es totalmente inviable. Pues bien, la solución adoptada en este caso es realizar una conexión reversa, es decir, es la víctima quien se comunica, sin saberlo, con un servidor del atacante. Entonces al atacante le bastará con enviar las órdenes a ese servidor suyo y los clientes infectados se encargarán de leerla y enviar los resultados. Digamos que se trata de una comunicación a tres bandas, el esquema se puede ver en la figura1. A continuación veamos un poco mejor como funciona todo esto.
El proceso de infección es el siguiente:
De esta lista se puede deducir lo peligroso que puede llegar a ser infectarse con una inyección de este tipo. Si el atacante tiene las herramientas adecuadas, simplemente el poder obtener cualquier cookie de la víctima ya proporciona acceso a infinidad de posibilidades. Como acceder a áreas privadas de las aplicaciones a las que se conecte habitualmente el usuario atacado.
Así pues, partiendo de que ya se ha realizado la infección y se ha configurado XSSShell, ahora bastará con arrancar el programa de control que se proporciona en el paquete, en concreto 'XSSTunnel/XSS Tunnel Binary Release/XSSTunnel.exe'.
Una vez arrancado aparece una ventana igual a la que se puede observar en la imagen4. Ésta ha sido sacada del propio manual que se puede descargar desde la web del proyecto.
Observando las opciones que aparecen en la captura se aprecia la configuración general del programa. Por un lado tenemos la configuración del servidor propiedad del atacante para la comunicación ( www.xssshellserver.com:6000/admin ) junto con el password utilizado para la autentificación, y por otro lado, se encuentra la configuración del Proxy que, en este caso, quedará a la escucha en el puerto 8080, y accesible desde cualquier interficie de red.
Después de configurarlo todo bastará esperar a que alguna víctima se conecte al site señuelo y configurar nuestro navegador para que utilice como proxy el servidor creado por XSSTunnel. Una vez realizadas estas acciones ya será posible navegar utilizando el navegador de la víctima, pudiendo controlar siempre la operación desde el programa XSSTunnel.exe tal y como se muestra en la imagen5, que forma parte también del manual disponible en la web. En ella se pueden observar las URL's que se han ido cargando a través del proxy.
Gracias a esta aplicación es posible acceder a áreas restringidas o hacernos pasar por la víctima con todos sus privilegios. Si un administrador de una entidad importante cayera en una trampa de este tipo, no sólo estaría comprometiéndose a él, si no que además pondría en peligro la seguridad entera de la empresa, ya que el atacante podría modificar tantos aspectos como los privilegios de su perfil permitieran.
La primera consiste en realizar una programación web segura y evitar este tipo de vulnerabilidades. Esta tarea no es tan fácil como puede parecer ya que actualmente el Cross-Site Scripting tiene tantas variantes que hace muy difícil la posibilidad de prevenirlas todas. Por este motivo entra en juego la segunda estrategia, que consiste en instalar un firewall de aplicación que se encargue de analizar las peticiones entrantes y salientes en busca de código malicioso, detectando así muchos de los ataques.
Un firewall de aplicación no deja de ser un proxy que interviene el tráfico antes de llegar al CGI y/o antes de ser enviado y lo analiza en busca de código malicioso o fugas de información, por ejemplo.
Existen varios, pero se va a hablar de uno distribuido bajo licencia GPL y que puede integrarse con el servidor web Apache, que es el servidor más extendido en entornos *nix.
Se denomina 'mod_security' y puede descargarse desde el siguiente enlace (ver imagen6):
Finalmente se encuentra el cliente, que es objetivo de ataques y engaños por su inocencia y otras veces, es víctima de un ataque por un fallo de programación cometido en un servidor, con lo que el usuario se infecta sin darse cuenta de nada en absoluto, en este caso hablaríamos de mala programación. Para el usuario también existen utilidades para protegerse, de hecho, actualmente los propios antivirus ya incorporan sistemas de detección de inyecciones a través de Internet, analizando el trafico entrante y saliente al mismo tiempo que se procesan los ficheros bajados desde la red en busca de código vírico.
Desafortunadamente la totalidad de antivirus no integran estas funcionalidades, y algunos que dicen hacerlo, no acaban de implementarlo de forma muy fiable. Además, también se ofrecen plugins para navegadores como Firefox que previenen ante este tipo de ataques analizando las peticiones, aunque aun así no se debe estar del todo seguros. Una ultima recomendación sería, en última instancia, desactivar el javascript, de esta forma se evita la infección, aunque por otra parte no se apreciarán los detalles 'dinámicos' hechos en este lenguaje.
Desde aquí os recomiendo que probéis en vuestras propias carnes una inyección de este tipo, teniendo en cuenta que gracias a 'portcullis-security' se encuentra disponible una buena “suite” de utilidades. Así que bastará con instalar un IIS en vuestra red local junto con XSSTunnel y probarlo en vivo. En la web de los autores se puede encontrar vídeos demostrativos del uso e instalación de XSS Shell y XSS Tunnel, no tienen desperdicio. De esta manera se podrá comprobar la seguridad del entorno más cercano y se comprobará como no se está tan seguro como uno pueda creer.
Si alguno creía que simplemente navegando no podía pasar nada, que se lo replantee, ya que cada día salen nuevos métodos y técnicas para ridiculizar tanto al usuario como a las empresas de antivirus y protecciones de Internet y ponerles en jaque.
Saludos y hasta otra!
El Navegador
Técnicamente, el navegador que se usa para visitar las páginas web, no es más que un intérprete de código que se comunica con un servidor. Como todo software ha ido evolucionando hasta tal punto que algo que era un simple navegador que permitía ver webs HTML y punto, ahora tiene otras mil funcionalidades.Para el tema que importa ahora, XSS; se debe hablar de la interacción que se puede llevar a cabo desde el navegador. Según el site que se esta visitando, se dispone de un tipo de interacción u otro, dependiendo de la tecnología web usada. Por ejemplo, una web estática sólo proporciona información, y un usuario no podrá realizar muchas más acciones que pulsar en un link directo, ya que todo ocurre en el propio navegador, en cambió en una web dinámica se puede interaccionar con el servidor de una manera mucho más directa, por ejemplo, realizando peticiones con parámetros.
Un pequeño listado de las tecnologías más “típicas” que soportan los navegadores actuales podrían ser: HTML, JavaScript, CSS... Cada una tiene su propia funcionalidad, además es posible añadir soporte para otro tipo de elementos, como Flash o Java, utilizando para ello plugins externos. Para poder ver la totalidad de tecnologías soportadas por los navegadores más usados, como Firefox e Internet Explorer, basta con acceder a las siguientes url respectivamente:
http://developer.mozilla.org/ http://www.microsoft.com/windows/ie/ie6/evaluation/features/default.mspxComo ya se ha dicho, cada uno de estas tecnologías web tiene su propia funcionalidad. Algunas simplemente se emplean para controlar el diseño y maquetación de la página web, para darle forma y color, HTML y CSS, e incluso JavaScript para añadir dinamismo. Otros, en cambio, pueden llegar a ejecutar código en la máquina del cliente pidiendo, evidentemente, permiso expreso, aunque no son pocos los casos en los que el usuario acepta sin tan siquiera leer los avisos emitidos por el navegador o por fruto de un engaño o despiste.
Con todo esto se quiere decir que el navegador puede realizar muchas funciones, algunas de las cuales pueden llegar a comprometer nuestra seguridad si se usan con malas intenciones. Algunos recordareis esos dialers de las páginas para adultos que se instalaban solos sin conocimiento del usuario. Es por eso que hay que dedicar especial atención a los mensajes procedentes de las visitas por Internet y aceptar solamente aquellos de los que se esté realmente seguro y provengan de una fuente de confianza.
La Inyección
El concepto de inyección no solo se utiliza para referirse a un ataque de tipo XSS, de hecho se denomina inyección de caracteres arbitrarios, ya sea para producir un XSS (Inyección de código interpretada por un cliente Web, generalmente HTML o Javascript) o un SQL Injection (Inyección SQL interpretable por el servidor de la base de datos), se produce cuando las entradas de los parámetros en un CGI (scripts/programas que se encargan de generar la web ) no están bien verificados. Consecuentemente, durante su ejecución en el momento de utilizar el valor del parámetro, se produce la inyección de todos los caracteres sin ningún tipo de validación, entonces es cuando se produce una inyección de código interpretable por el navegador/servidor dependiendo del caso.Según la inyección, el problema es más o menos serio, en este artículo se hablará de la inyección de código HTML y Javasciprt, ya que son lenguajes que afectan directamente al cliente. También se podría hablar de inyecciones en el servidor, pero entonces sería otro tipo de problema: SQL Injection, PHP Injection, IMAP/SMTP Injection, LDAP Injection, SSI Injection.... Y sería una explicación demasiado extensa.
El XSS no es más que una inyección HTML o Javascript, como ya se ha dicho anteriormente. Veamos un simple código a modo de ejemplo, meramente conceptual y que no funciona:
xss.cgi: 1:<HTML> 2: <BODY> 3: <? print $GET['var1']; ?> 4: </BODY> 5:</HTML>
http://www.server.com/xss.cgi?var1=prueba
IMAGEN 1
La respuesta sería una web en blanco con la palabra “prueba” escrita al inicio (ver imagen1). Nada peligroso por el momento. Veamos ahora otro tipo de comportamiento. Añadiendo etiquetas HTML al valor de la variable podemos modificar el código resultante. Por ejemplo, pasando la cadena: 'user:<input type="text" length="25" /><br />pass:<input type="pass" length="25" />' directamente, es decir, con la llamada:
http://www.server.com/xss.cgi?var1=user:<input type="text" length="25" /><br />pass:<input type="pass" length="25" />
IMAGEN 2
Phising
Dependiendo de las motivaciones de quien realice la inyección se utilizará para un fin u otro. Principalmente destacan los ataques de phising que muchas veces se aprovechan de vulnerabilidades de XSS en las aplicaciones web alojadas servidores lícitos para hacerse pasar por ellos, robando así los credenciales de la víctima. Si se hiciera un ataque de este tipo a un banco, el atacante podría tener acceso total a las cuentas de la víctima. De hecho, cada día son más los casos de phising en todo el mundo, el correo SPAM que tanto se odia, muchas veces tiene ese objetivo, hacer creer realidades que no son, como por ejemplo tener que validar la contraseña de acceso al banco por algún problema técnico que ha tenido este.Para realizar este ataque bastaría con imitar un formulario de login en la web vulnerable y enviar los datos a un servidor privado controlado por el atacante. Después, para infectar al usuario bastaría con postear el link o enviárselo por correo (spam). El esqueleto del código inyectado podría ser parecido al utilizado en el primer ejemplo y el resultado análogo al de la imagen2, sólo que con la estética de la web vulnerable que se pretenda suplantar.
Malware
Otra posible finalidad es la instalación de Malware en la máquina del cliente haciéndose pasar por el servidor de la entidad. Esto se podría conseguir añadiendo algunas líneas de código que fueran suficientes para que el navegador hiciera una petición de descarga al servidor controlado por el atacante. El XSS entra en juego para camuflar al atacante. Al realizar la inyección del código necesario en la web original, crea al usuario la sensación de seguridad de que se esta descargando el programa del sitio correcto, ya que él está visitando esa web en ese instante.Los programas descargados de esta manera pueden ser tanto un fichero que luego es necesario que el usuario lo ejecute confiando con el origen en una fuente de confianza, a modo de actualización por ejemplo, o bien un applet Java o ActiveX. Que se encargará de hacer todas las acciones necesarias para la infección. Así que hay que asegurarse siempre bien de dónde se están bajando los ficheros y validar la autoría del remitente.
Técnicas Avanzadas
Lo visto hasta ahora es lo 'típico', pero también existen otras posibilidades de las que no se habla tanto, aunque tengan algún que otro año de vida. La compañía 'Portcullis Computer Security', en concreto Ferruh Mavituna, por ejemplo ha realizado unas aplicaciones realmente interesantes que aprovechan de manera óptima todo lo relacionado con el concepto de Cross-SiteScripting. Las herramientas en concreto se denominan XSS-Tunnel y XSS-Shell y pueden conseguirse en el siguiente enlace:http://www.portcullis-security.com/16.phpEn esta página se pueden observar todas las aplicaciones gratuitas que ofrecen, todas ellas bastante interesantes (ver imagen3).
IMAGEN 3
El objetivo de XSS Shell es controlar el navegador de la víctima, mientras que XSS Tunnel llega un poco más allá y es capaz de crear un canal de comunicación entre el atacante y la red, pasando por la víctima o, lo que es lo mismo, un proxy. Ambas se sirven de la misma técnica, inyectar código javascript para infectar el navegador al mismo tiempo que regeneran la web vulnerable a ataques de tipo XSS. De esta manera se mantiene a la víctima en un entorno virtual controlado, aunque este echo supone alguna que otra restricción. Por ejemplo, si pensamos en los navegadores actuales con pestañas, en este caso solo se infectaría la pestaña que hubiera accedido a la web maliciosa, quedando todas las demás fuera del alcance de la infección.
La primera pregunta que viene a la cabeza es el funcionamiento de la comunicación entre el atacante y la víctima para poder crear el canal de comunicación, ya que, a priori, una conexión directa es totalmente inviable. Pues bien, la solución adoptada en este caso es realizar una conexión reversa, es decir, es la víctima quien se comunica, sin saberlo, con un servidor del atacante. Entonces al atacante le bastará con enviar las órdenes a ese servidor suyo y los clientes infectados se encargarán de leerla y enviar los resultados. Digamos que se trata de una comunicación a tres bandas, el esquema se puede ver en la figura1. A continuación veamos un poco mejor como funciona todo esto.
FIGURA 1
XSS-Shell
XSS-Shell esta formado por dos componentes, el que infecta y el que se encuentra en el servidor del atacante. Todo el código esta escrito en ASP .NET y VBS, consecuentemente, el servidor donde se encontrará el motor de la comunicación (XSS Shell server) deberá ser sobre Windows con .NET Framework 2.0 (mínimo). XSS Shell permite, además, configurar una contraseña para acceder al panel de administración. De esta manera la aplicación no puede ser vista por nadie sin el consentimiento expreso del propietario, además de evitar el robo de víctimas entre atacantes.El proceso de infección es el siguiente:
- Se configura el servidor de XSS-Shell.
- Se realiza la inyección en una web o bien se postea un Link malicioso en algún foro.
- Se espera a que algún usuario caiga en la trampa.
TABLA 1
| Get Cookie | Devuelve la cookie de la víctima de un dominio al azar. |
| Get Current Page | Devuelve la página actual. |
| Execute custom Javascript | Ejecución de código javascript arbitrario. |
| Get Mouse Log | Devuelve los movimientos del ratón. |
| Get Keylogger Data | Devuelve las teclas presionadas en la pestaña infectada. |
| Get Cllipboard | Devuelve el contenido del portapapeles de la víctima. |
| Get Internet IP Address | Devuelve la IP de la red local de la víctima. |
| Check Visited links | Verifica si ha visitado ciertas páginas basándose en el hack del CSS * |
| Crash Browser | Cierra el navegador de la víctima. |
De esta lista se puede deducir lo peligroso que puede llegar a ser infectarse con una inyección de este tipo. Si el atacante tiene las herramientas adecuadas, simplemente el poder obtener cualquier cookie de la víctima ya proporciona acceso a infinidad de posibilidades. Como acceder a áreas privadas de las aplicaciones a las que se conecte habitualmente el usuario atacado.
XSS-Tunnel
Esta herramienta, como ya se ha comentado anteriormente, se sirve de las funcionalidades ofrecidas por XSS-Shell para llevarlas un poco más allá y acabar utilizando la víctima como proxy. El proceso necesario para la utilización de esta herramienta es prácticamente el mismo que se ha comentado anteriormente para XSS-Shell.Así pues, partiendo de que ya se ha realizado la infección y se ha configurado XSSShell, ahora bastará con arrancar el programa de control que se proporciona en el paquete, en concreto 'XSSTunnel/XSS Tunnel Binary Release/XSSTunnel.exe'.
Una vez arrancado aparece una ventana igual a la que se puede observar en la imagen4. Ésta ha sido sacada del propio manual que se puede descargar desde la web del proyecto.
IMAGEN 4
Observando las opciones que aparecen en la captura se aprecia la configuración general del programa. Por un lado tenemos la configuración del servidor propiedad del atacante para la comunicación ( www.xssshellserver.com:6000/admin ) junto con el password utilizado para la autentificación, y por otro lado, se encuentra la configuración del Proxy que, en este caso, quedará a la escucha en el puerto 8080, y accesible desde cualquier interficie de red.
Después de configurarlo todo bastará esperar a que alguna víctima se conecte al site señuelo y configurar nuestro navegador para que utilice como proxy el servidor creado por XSSTunnel. Una vez realizadas estas acciones ya será posible navegar utilizando el navegador de la víctima, pudiendo controlar siempre la operación desde el programa XSSTunnel.exe tal y como se muestra en la imagen5, que forma parte también del manual disponible en la web. En ella se pueden observar las URL's que se han ido cargando a través del proxy.
Gracias a esta aplicación es posible acceder a áreas restringidas o hacernos pasar por la víctima con todos sus privilegios. Si un administrador de una entidad importante cayera en una trampa de este tipo, no sólo estaría comprometiéndose a él, si no que además pondría en peligro la seguridad entera de la empresa, ya que el atacante podría modificar tantos aspectos como los privilegios de su perfil permitieran.
IMAGEN 5
Soluciones y Precauciones
Para abordar este problema se deben plantear dos puntos de vista: el del servidor por una parte y el del cliente por otra. Como se deduce de esto, la responsabilidad del problema recae en el propietario del servidor o de las aplicaciones que contienen webs vulnerables a inyección de código. Hay que decir que este tipo de vulnerabilidad es la primera en el ranking 2007 de vulnerabilidades realizado por la organización OWASP ( http://www.owasp.org - Open Web Application Security Project ), así que es bastante numeroso. Así pues, para protegerse de este tipo de ataque existen fundamentalmente dos estrategias a elegir, aunque se deberían usar conjuntamente.La primera consiste en realizar una programación web segura y evitar este tipo de vulnerabilidades. Esta tarea no es tan fácil como puede parecer ya que actualmente el Cross-Site Scripting tiene tantas variantes que hace muy difícil la posibilidad de prevenirlas todas. Por este motivo entra en juego la segunda estrategia, que consiste en instalar un firewall de aplicación que se encargue de analizar las peticiones entrantes y salientes en busca de código malicioso, detectando así muchos de los ataques.
Un firewall de aplicación no deja de ser un proxy que interviene el tráfico antes de llegar al CGI y/o antes de ser enviado y lo analiza en busca de código malicioso o fugas de información, por ejemplo.
Existen varios, pero se va a hablar de uno distribuido bajo licencia GPL y que puede integrarse con el servidor web Apache, que es el servidor más extendido en entornos *nix.
Se denomina 'mod_security' y puede descargarse desde el siguiente enlace (ver imagen6):
www.modsecurity.orgEn esta web, además, se encuentran disponibles multitud de documentos explicando el funcionamiento y configuración. La configuración se basa en expresiones regulares que hacen saltar las alarmas en caso de que se cumplan, estas afectan a toda la petición http, desde el User-Agent hasta el contenido web, petición POST, GET... eso permite que sean muy personalizables y, por lo tanto, adaptables a cada situación del servidor en particular a un nivel granular tan afinado como se quiera - Desde aquí aconsejo un paseo por dicha web para comprender mejor como esta estructurado todo el proyecto.
IMAGEN 6
Finalmente se encuentra el cliente, que es objetivo de ataques y engaños por su inocencia y otras veces, es víctima de un ataque por un fallo de programación cometido en un servidor, con lo que el usuario se infecta sin darse cuenta de nada en absoluto, en este caso hablaríamos de mala programación. Para el usuario también existen utilidades para protegerse, de hecho, actualmente los propios antivirus ya incorporan sistemas de detección de inyecciones a través de Internet, analizando el trafico entrante y saliente al mismo tiempo que se procesan los ficheros bajados desde la red en busca de código vírico.
Desafortunadamente la totalidad de antivirus no integran estas funcionalidades, y algunos que dicen hacerlo, no acaban de implementarlo de forma muy fiable. Además, también se ofrecen plugins para navegadores como Firefox que previenen ante este tipo de ataques analizando las peticiones, aunque aun así no se debe estar del todo seguros. Una ultima recomendación sería, en última instancia, desactivar el javascript, de esta forma se evita la infección, aunque por otra parte no se apreciarán los detalles 'dinámicos' hechos en este lenguaje.
Conclusiones
Después de estas pinceladas sobre las posibles aplicaciones del XSS, seguro que a nadie se le escapa la importancia de una buena protección frente a estas amenazas.Desde aquí os recomiendo que probéis en vuestras propias carnes una inyección de este tipo, teniendo en cuenta que gracias a 'portcullis-security' se encuentra disponible una buena “suite” de utilidades. Así que bastará con instalar un IIS en vuestra red local junto con XSSTunnel y probarlo en vivo. En la web de los autores se puede encontrar vídeos demostrativos del uso e instalación de XSS Shell y XSS Tunnel, no tienen desperdicio. De esta manera se podrá comprobar la seguridad del entorno más cercano y se comprobará como no se está tan seguro como uno pueda creer.
Si alguno creía que simplemente navegando no podía pasar nada, que se lo replantee, ya que cada día salen nuevos métodos y técnicas para ridiculizar tanto al usuario como a las empresas de antivirus y protecciones de Internet y ponerles en jaque.
Saludos y hasta otra!
EOF