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

No se puede evitar un abrumador ataque DDoS, pero se puede minimizar su impacto. He aquí cómo.

Los ataques de denegación de servicio (DoS) -particularmente el ataque distribuido de denegación de servicio (DDoS)-  han afectado a muchas empresas recientemente, desde Sony hata el Bank of America. 

Durante años, la mayoría de las compañías amortizaron los ataques DoS, como un riesgo aceptable, ya que la probabilidad de convertirse en víctima era relativamente bajo y el riesgo de daño a la empresa también lo era. Recientemente, sin embargo, esta clase de ataque ha aumentado en popularidad, haciendo que muchas organizaciones reconsideren el riesgo relativo. Directores ejecutivos están preocupados por la pérdida de ingresos y la mala prensa, las TI se preocupan por las aplicaciones bloqueadas y largas horas de trabajo.

Aunque no se puedan prevenir todos los ataques DDoS, hay opciones para limitar su eficacia y permitir que su organización se recuperé más rápido. En la mayoría de los recientes ataques contra aplicaciones Web, los atacantes simplemente envian más solicitudes que la aplicación Web puede manejar, lo que dificulta a los visitantes el utilizarla.

En este tipo de ataques, la mayoría de los atacantes no están preocupados por si el sistema y la aplicación se bloquea en realidad, aunque estarían felices si se produce un bloqueo. Su principal objetivo es evitar que los servicios ofrecidos por la compañía apuntada, responda a las peticiones de los usuarios legítimos, causando problemas para la empresa víctima.

Si usted tiene un control adecuado de la tecnología, estos ataques son fáciles de detectar. Su Network Operations Center (NOC) estará en status quo para el ancho de banda, las solicitudes por segundo y el uso de recursos del sistema con tendencia normal. Entonces, ya sea repentina o después de una pequeña cantidad de tiempo, todas estas tendencias se disparan hacia arriba, se alcanzará los umbrales, y las alertas se enviarán por el sistema de monitoreo.

En una organización típica, estos eventos darán lugar a una escalada en el NOC, y el equipo de TI se apresurará a conseguir a la gente indicada. Gestión recibirá un aviso de que los sitios y las aplicaciones están respondiendo inusualmente, y todos se preguntarán que por qué hay un gran aumento en las solicitudes en un período de tiempo tan corto.

A menos que su sitio haya sido mencionado en la portada de Slashdot, lo más probable es que usted esté experimentando el comienzo de un ataque DDoS. ¡Felicitaciones! Usted es ahora parte del club de las organizaciones que han sido objeto de un ataque DDoS -generalmente porque los atacantes no son seguidores de sus políticas corporativas, o porque se les paga para que ataquen.

El primer paso es analizar los registros de solicitudes.

Leer el resto de este artículo aquí.

Los problemas de seguridad dan a muchas empresas la pausa para que consideren migrar parte de sus operaciones de TI a servicios basados ​​en la nube. Pero se puede mantener la seguridad en la nube. En este informe del Centro de Lectura Dark Tech, que explicará los riesgos y le guiará en el establecimiento de políticas adecuadas de seguridad en la nube, los procesos y controles.

Leer el reporte de Dark Reading (Requiere de un registro gratuito para consultar).

Fuente: Information Week  JRS/GC

La mayoría de las empresas, a pesar de tener numerosas aplicaciones de misión crítica accesible a través de sus sitios web, fallan al asignar suficientes recursos financieros y técnicos para asegurar y proteger las aplicaciones Web, dejando los datos corporativos vulnerables al robo. Este es uno de los resultados de un estudio de Imperva, WhiteHat Security y el Instituto Ponemon.

Segun el estudio, la mayoría de los encuestados cree que las aplicaciones Web inseguras representan la mayor amenaza a los datos corporativos. Sin embargo, el 70 por ciento señaló que sus organizaciones no consideran la aplicación de seguridad como una iniciativa estratégica, ni tampoco creen que sus organizaciones tienen suficientes recursos específicamente en el presupuesto en la seguridad de aplicaciones Web para enfrentar el riesgo.

El estudio encontró que sólo el 18 por ciento de los presupuestos de TI en seguridad fueron asignados para hacer frente a la amenaza planteada para aplicaciones Web inseguras, mientras que el 43 por ciento de los presupuestos de TI en seguridad fueron asignados a las redes y seguridad de host, las áreas encuestadas parecían ser de menos preocupación.

De las 10 violaciones de datos en 2009, según la Organización de Derechos de Privacidad, el 93 por ciento de los registros comprometidos fueron robados como resultado de ataques maliciosos o criminales contra las aplicaciones Web y bases de datos – la mayoría de las empresas aún siguen estando muy expuestas.

El estudio de Ponemon reveló que el 61 por ciento de las organizaciones mencionaron tener hasta 100 aplicaciones Web expuestas al publico que realizan transacciones o accesan a millones de registros de clientes. Y además, la mayoría de las organizaciones no ha hecho una aplicación de seguridad de alta prioridad. La encuesta encontró que la gran mayoría de los desarrolladores están demasiado ocupados para responder a las cuestiones de seguridad Web.

“La mayoría de las más grandes y recientes violaciones de datos hasta la fecha han sido el resultado de los ataques contra las aplicaciones Web”, explicó Jeremiah Grossman, fundador de CTO y WhiteHat. “Para hacer frente a las amenazas cibernéticas actuales, las empresas deben cambiar su estrategia de seguridad – y presupuestos – de ser predominantemente basada en las infraestructuras y dar prioridad a los datos y aplicaciones directamente.

Recomendaciones

*No se puede asegurar lo que no sabe que posee – un inventario de sus aplicaciones Web para obtener mayor visibilidad de los datos que están en riesgo y donde los atacantes pueden explotar el dinero o los datos de la transacción.

*Asignar un defensor – Designe a alguien que puede impulsar y dirigir la seguridad de datos y esté altamente capacitado para dirigir numerosos equipos de soporte. Sin rendición de cuentas, la seguridad y el cumplimiento, sufrirán.

*No espere a que los desarrolladores tomen cargo de la seguridad – Implementar tecnologías de protección para mitigar el riesgo de vulnerabilidad en las aplicaciones Web.

*Cambie el presupuesto de la infraestructura para la seguridad de aplicaciones Web – Con la asignación de recursos, el riesgo empresarial puede ser dramáticamente reducido.

El estudio de Ponemon encuestó a 627 profesionales de TI y a más de 400 empresas multinacionales y organizaciones gubernamentales.

Fuente: Help Net Security  CLA/RS