Definición

XSS es un ataque de inyección de código malicioso para su posterior ejecución que puede realizarse a sitios web, aplicaciones locales e incluso al propio navegador.

Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación web y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio web, mensajería instantánea o un correo electrónico. Así mismo, puede provocar una negación de servicio (DDos).

Fig. 1. Operación de un ataque XSS

Generalmente, si el código malicioso se encuentra en forma de hipervínculo es codificado en HEX (basado en el sistema de numeración hexadecimal, base 16) o algún otro, así cuando el usuario lo vea, no le parecerá sospechoso. De esta manera, los datos ingresados por el usuario son enviados a otro sitio, cuya pantalla es muy similar al sitio web original.

De esta manera, es posible secuestrar una sesión, robar cookies y cambiar la configuración de una cuenta de usuario.

Tipos de ataques

Las diversas variantes de esta vulnerabilidad pueden dividirse en dos grandes grupos: el primero se conoce como XSS persistente o directo y el segundo como XSS reflejado o indirecto.

Directo o persistente. Consiste en invadir código HTML mediante la inclusión de etiquetas y en sitios que lo permiten.

Local. Es una de las variantes del XSS directo, uno de sus objetivos consiste en explotar las vulnerabilidades del mismo código fuente o página web. Esas vulnerabilidades son resultado del uso indebido del DOM (Modelo de Objetos del Documento, es un conjunto estandarizado de objetos para representar páginas web) con JavaScript, lo cual permite abrir otra página web con código malicioso JavaScript incrustado, afectando el código de la primera página en el sistema local. Cuando el XSS es local, ningún código malicioso es enviado al servidor. El funcionamiento toma lugar completamente en la máquina del cliente, pero modifica la página proporcionada por el sitio web antes de que sea interpretada por el navegador para que se comporte como si se realizara la carga maliciosa en el cliente desde el servidor. Esto significa que la protección del lado del servidor que filtra el código malicioso no funciona en este tipo de vulnerabilidad.

Indirecto o reflejado. Funciona modificando valores que la aplicación web pasa de una página a otra, sin emplear sesiones. Sucede cuando se envía un mensaje o ruta en una URL, una cookie o en la cabecera HTTP (pudiendo extenderse al DOM del navegador).

Consideraciones

Como desarrollador

La aplicación web que se desee implementar debe contar con un buen diseño. Posteriormente, se deben realizar diversos tipos de pruebas antes de su liberación, para detectar posibles fallos y  huecos de seguridad, mediante el empleo de alguna herramienta automatizada. También, es conveniente proporcionar mantenimiento a la aplicación y estar actualizado en las versiones de las herramientas que se emplean para su puesta en marcha.

Algunas recomendaciones para mitigar el problema, son:

Emplear librerías verificadas o algún framework que ayude a disminuir el inconveniente. Por ejemplo: la librería anti-XSS de Microsoft, el módulo ESAPI de codificación de OWASP, Apache Wicket, entre otros.

Entender el contexto en el cual los datos serán usados y la codificación de los mismos, este aspecto es importante cuando se envían datos de un componente a otro de la aplicación o cuando se deben enviar a otra aplicación.

Conocer todas las áreas potenciales donde las entradas no verificadas pueden acceder al software: parámetros o argumentos, cookies, información de la red, variables de entorno, resultados de consultas, búsqueda de DNS reversible, peticiones enviadas en las cabeceras, componentes de la URL, correos electrónicos, archivos, nombres de archivo, bases de datos o algún sistema externo que proporcione información a la aplicación.

Las validaciones de datos de entrada, deben realizarse siempre del lado del servidor, no sólo en el lado del cliente. Los atacantes pueden evitar la validación realizada del lado del cliente modificando valores antes de realizar verificaciones o remover por completo esta validación.

En caso de ser posible, emplear mecanismos automatizados para separar cuidadosamente los datos del código fuente: revisión de comillas, codificación y validación automática que muchas veces se escapan al desarrollador.

Por cada página web generada, se recomienda emplear una codificación determinada de caracteres, ya que si no se especifica, el navegador puede dar un trato diferente a ciertas secuencias de caracteres especiales, permitiendo la apertura del cliente a posibles ataques.

Para mitigar el problema de ataque contra el uso de cookies, es conveniente indicar que tiene el formato de HttpOnly. En los navegadores que lo soportan, puede prevenirse que la cookie sea usada por scripts maliciosos desde el lado del cliente.

Se debe emplear una estrategia de validación de las entradas: rechazar aquellas que no cumplan con lo especificado, limpiar las que sean necesarias. Al validar, considérense  las características de cada entrada: longitud, tipo de dato, rango de valores aceptados, entradas perdidas o adicionales, sintaxis, consistencia con otras entradas proporcionadas y seguimiento de las reglas del negocio.

Cuando se construyan páginas web de forma dinámica (generadas de acuerdo a las entradas o solicitudes de los usuarios), es recomendable usar listas blancas estrictas. Todas las entradas deben ser limpiadas y validadas, incluidos cookies, campos ocultos, cabeceras y la propia dirección.

Cuando una cantidad aceptable de objetos, como nombres de archivo o URL es limitada o conocida, es conveniente crear una conjunto de asignaciones de valores de entrada fijo a los nombres de archivo o URL y rechazar todos los demás.

Se recomienda usar un firewall de aplicaciones capaz de detectar ataques cuando el código se genere dinámicamente, como medida de prevención, debe complementarse con otras para proporcionar defensa en profundidad.

Como Administrador de Bases de Datos

Así como el desarrollador debe validar las entradas proporcionadas por parte del usuario, el encargado de diseñar e implementar la base de datos debe considerar la seguridad de la misma, pues en ella se guarda la información proporcionada por los usuarios y es manipulada mediante la aplicación web. Los datos que serán almacenados, también pueden ser validados mediante el uso de constraints  (restricciones aplicables a los objetos de una base de datos: unique, default, not null, check) que restringen la entrada para cada campo.

PDF XSS

Es una vulnerabilidad ampliamente usada para afectar el Acrobat Reader de Adobe. En este caso, si se abusa de las características para abrir archivos en Acrobat, un sitio bien protegido se vuelve vulnerable a un ataque de tipo XSS si da alojamiento a documentos en formato PDF.

Esto afecta seriamente, a menos que se actualice el Reader o se cambie la forma en que el navegador maneja dichos documentos.

Una manera de combatirlo, si se cuenta con el servidor de aplicaciones web Apache, es llevar a cabo la correcta configuración de ModSecurity, ya que cuenta con directivas de protección para archivos en formato PDF.

XSRF

Un ataque Cross-Site Request Forgery (XSRF ó también CSRF) explota la confianza que un usuario tiene hacia las entradas proporcionadas por un sitio.

Por ejemplo: un usuario se encuentra autenticado y navegando en un sitio, en ese momento un atacante obtiene el control de su navegador, con él realiza una solicitud a una tarea de una URL válida del sitio, por lo que el atacante tendrá acceso como si fuera el usuario previamente registrado.

Distintivamente, un atacante intercalará código HTML o JavaScript malicioso en un correo o en una tarea específica accesible desde una URL, que se ejecuta ya sea directamente o empleando un error de tipo XSS. También, es posible realizar inyección a través de lenguajes como el BBCode. Este tipo de ataques son difíciles de detectar.

Muchas de las funcionalidades de un sitio web son susceptibles de uso durante un ataque XSRF. Esto incluye información enviada tanto por GET como por POST.

También puede usarse como vector para explotar vulnerabilidades de tipo XSS en una aplicación. Ejemplos de ello son: una vulnerabilidad de tipo XSS en un foro donde un atacante puede obligar al usuario a publicar –sin que éste se dé cuenta- un gusano informático. Un atacante puede también usar XSRF para transmitir un ataque a algún sitio de su elección, así como realizar un DDos.

Sin embargo, las formas más comunes de realizar este tipo de ataque consisten en usar la etiqueta HTML o el objeto JavaScript empleados para imágenes. Distintivamente, el atacante infiltrará un email o sitio web en ellos, así cuando el usuario cargue la página o el correo electrónico, también estará realizando la petición a la URL que haya colocado el atacante.

Un atacante puede instalar su script dentro de un documento de Word, un archivo de flash, un clip de video, redifusión web RSS o Atom, o algún otro tipo de formato que pueda alojar el script.

Si un sitio web permite ejecutar sus funciones empleando una URL estática o peticiones POST, es posible que sea vulnerable, si la función se lleva a cabo mediante la petición GET, el riesgo es mayor. Si se realizan las mismas funciones,  de la misma forma repetidamente, entonces la aplicación puede ser vulnerable.

Un ataque XSRF no puede evitarse mediante la verificación del referer de las cabeceras de la petición realizada, ya que puede “limpiarse” o modificarse mediante algún tipo de filtro. Las cabeceras pueden falsearse usando XMLHTTP, por ejemplo.

Una de las soluciones más conocidas, consiste en adjuntar un token no predecible y cambiante a cada petición. Es importante que el estado de éste vaya asociado con la sesión del usuario, de otra manera un atacante puede adjuntar su propio token válido y emplearlo en su beneficio. Adicionalmente, al ligarlo a la sesión del usuario es importante limitar el periodo durante el cual será válido.

Referencias.

Mesografía.

· http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

· http://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)

· http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html

· http://www.cgisecurity.com/csrf-faq.html

· http://www.isecpartners.com/files/XSRF_Paper_0.pdf

· http://www.techrepublic.com/blog/security/what-is-cross-site-scripting/426

· http://cwe.mitre.org/data/definitions/79.html

Una herramienta liberada dentro del Black Hat 2012 puede probar si firewalls de aplicaciones son vulnerables a técnicas de evasión de protocolos de capas.

Una herramienta hecha para realizar pruebas de vulnerabilidad sobre firewalls de aplicaciones web (Web Application Firewalls, o WAFs), con cerca de 150 técnicas de evasión a nivel protocolo, fue liberada en la conferencia Black Hat USA 2012.

La herramienta y la investigación necesaria para su creación son el fruto de Ivan Ristic, director de ingeniería del proveedor de seguridad Qualys y autor original del popular firewall para web, ModSecurity.

Los firewalls para aplicaciones web son diseñados para proteger a las aplicaciones web de ataques conocidos, tal es el caso de ataques de inyección SQL, que son comúnmente utilizados para comprometer sitios web. Los WAFs logran esto mediante la intercepción de peticiones enviadas por los clientes, aplicando estrictas reglas sobre el formato y contenido de las mismas.

Sin embargo, existen varios métodos para que las peticiones maliciosas violen las reglas establecidas por los WAFs, al modificar ciertas partes de sus cabeceras o las rutas de los URLs solicitados. Estas se conocen como técnicas de evasión a nivel de protocolo, y los WAFs no están apropiadamente equipados para lidiar con ellas actualmente porque estas técnicas no están bien documentadas, comentó Ristic.

El investigador probó las técnicas de evasión encontradas primordialmente contra ModSecurity, un WAF de código abierto, pero es razonable asumir que otros WAFs son vulnerables a algunas de ellas igualmente.

De hecho, Ristic dijo que compartió algunas de las técnicas con otros durante la etapa de investigación, y que habían sido exitosas contra algunos productos WAF comerciales. 

Erwin Huber Dohner, jefe de investigación y desarrollo del fabricante suizo de WAF Ergon Informatik, confirmó después de ver la presentación de Ristic que los métodos de evasión son un problema para la industria. Ergon recientemente identificó algunas técnicas similares que funcionaron contra sus productos, las cuales ya han sido corregidas, comentó.

Al hacer pública su investigación, Ristic espera iniciar una discusión en la industria sobre evasión a nivel protocolo y de otros tipos. Un wiki también se ha configurado, con el propósito de construir un catálogo libremente disponible de técnicas de evasión contra WAFs.

Si los fabricantes e investigadores de seguridad no documentan sus problemas y los hacen públicos, los desarrolladores de WAFs continuarán cometiendo los mismos errores, dijo Ristic.

Además, la disponibilidad de la herramienta permite a los usuarios descubrir qué productos WAF son vulnerables, y posiblemente obligar a los fabricantes a corregirlos.

Cada fabricante tiene diferentes prioridades y normalmente no corrigen problemas hasta que existe un riesgo real para sus clientes, comentó Ristic. Dijo que espera que este proyecto de investigación genere el incentivo necesario para que comiencen a lidiar con estos problemas.

Dohner aprobó la iniciativa y cree que tanto los fabricantes como los usuarios de WAF se beneficiarán de ella.

Fuente: Techworld SB

El proveedor de software Coverity ha liberado su reporte de riesgos de seguridad de software, el cual afirma que menos de dos quintas partes de compañías de desarrollo web se encargan de realizar pruebas durante el ciclo de desarrollo y que más de la mitad rechaza verificar sus códigos de fallos y vulnerabilidades de seguridad antes de las pruebas de integración.

De acuerdo al estudio, el resultado se traduce en más incidentes de seguridad en aplicaciones web y con más frecuencia, dando lugar a mayores costos generales.

La empresa especializada en el aseguramiento de calidad de software en EUA comisionó a la consultora Forrester llevar a cabo el estudio sobre la seguridad de las aplicaciones y pruebas. En julio, Forrester encuestó a 240 personas con grado de influencia que trabajan en empresas de desarrollo web de Europa y Norte América.

Mas del 70% de encuestados quienes habían experimentado previamente un incidente de seguridad se quejaron de una falta de tecnologías y procesos de seguridad para sus desarrolladores.

También hubo problemas con la escalabilidad y el presupuesto con una gran mayoría del 79% diciendo que no podían seguir el ritmo con volúmenes de código en aumento y más de dos terceras partes dicen que el financiamiento de la seguridad es insuficiente. 41% considera  que debido a un corto tiempo del lanzamiento al mercado se ven obligados a restar prioridad a la seguridad.

Unicamente el 42% cumplía con directrices de codificación segura y menos de un tercio contaba con una biblioteca de funciones autorizadas y prohibidas. Solo alrededor de una cuarta parte utilizó el modelado de amenazas durante el desarrollo.

Más de la mitad de los encuestados habían sufrido al menos una brecha de seguridad en los últimos 18 meses. El 18% había sufrido pérdidas de $500 mil dólares y un 8% sufrió pérdidas  de más de $1 millón de dólares.

La pobre integración con sus entornos de desarrollo, demasiada experiencia de seguridad requerida y un gran número de falsos positivos fueron citados como los tres más grandes desafíos al tratar con herramientas de seguridad para aplicaciones web. Aunque algunos de los expertos en seguridad encuestados estuvieron de acuerdo en que la integración de herramientas es un desafío, no creen que las herramientas de seguridad sean demasiado complejas o requieran  de mucha experiencia.

Fuente: The H Security OM