cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

400510401. Cuando las aplicaciones sufren ataques

Escrito por Redacción en Tema de portada
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

Las aplicaciones, particularmente las basadas en web, constituyen un nuevo terreno de batalla. Los administradores de redes y los arquitectos de aplicaciones están encarando el reto de replantearse los métodos utilizados o emplear nuevas medidas para mantener la eficacia de las barreras de seguridad. Al mismo tiempo los nuevos requisitos legales como el estándar de seguridad PCI (Payment Industry Card) están otorgando mayor importancia a la seguridad de aplicaciones.

En términos tecnológicos, ¿qué tienen en común los nuevos sistemas operativos con los tipos de aplicaciones? Obviando algunas ilustres excepciones, la respuesta es una enorme falta de seguridad como parte esencial del desarrollo de los mismos. No se trata de una crítica ‘per se’.

Por norma general, los desarrolladores de aplicaciones lidian con una serie de prioridades (idoneidad al propósito, usabilidad, etc.) superiores a la incorporación del complicado y costoso código de seguridad.La reciente proliferación de aplicaciones web – que podríamos arriesgarnos en determinar casi como la ‘webificación de las aplicaciones’- arrojó escasa luz sobre la seguridad de éstas, cuestión que en realidad acaba de focalizarse como una necesidad patente. ¿Por qué ahora?

Lo que podría ser parafraseado como “lo que se convierte en popular, se convierte también en objetivo” no es más que una obviedad. Windows es indudablemente el sistema operativo más utilizado globalmente y se enfrenta a una enorme cantidad de ataques procedentes de Internet. De forma paralela, el sistema operativo MAC ha ganado enteros desde 2001 – año del lanzamiento de iPod- y lo mismo ha hecho el malware (software malicioso) destinado al sistema Apple. Tan sólo dos de los muchos ejemplos existentes.

[(De forma paralela, el sistema operativo Mac ha ganado enteros desde 2001 – año del lanzamiento de iPod- y lo mismo ha hecho el malware (software malicioso) destinado al sistema Apple)]

Una de las cosas que sí puede afirmarse acerca de la seguridad es que se trata de una lucha sin final. Los vectores de los ataques cambian continuamente ya que los hackers se hacen cada vez más listos (spam evoluciona hacia phishing) y varían también las motivaciones (desde fama hacia dinero).

Paralelamente, las compañías dedicadas a la seguridad cierran todas las puertas que pueden para encontrarse con otras nuevas abiertas de par en par: mientras se clausuran algunos antiguos vectores de ataques, quedan patentes otros nuevos. A medida que transcurre el tiempo asistimos a una masiva proliferación de formas de ataques cada vez más sofisticadas cuya compensación crece en la misma proporción de cómo lo hacen los fraudes.

El crecimiento de aplicaciones basadas en web tales como las herramientas del SAP o Salesforce.com, entre otras, utilizadas para ‘refinar’ la información en bruto de los centros de datos y presentarla a los comerciales, clientes y otras muchas formas de usuarios constituye tan sólo uno de los objetivos de los ataques. Para el propósito del presente artículo, analizaremos por qué estas aplicaciones web (web apps) son tan vulnerables y qué podemos hacer para remediarlo.

‘WEB APPS’: ¿cuál es el problema?

Con el fin de proteger las aplicaciones web, se utiliza habitualmente un paquete de filtros multi-nivel que, en definitiva, implica ubicar los diferentes componentes de una aplicación web (servidor web de front-end, servidor de aplicaciones, servidor de back-end) en zonas distintas. Ver la Figura 1.

Esos componentes o sistemas en cada una de las zonas se configuran en modo seguro logrando así un refuerzo del sistema operativo. El hacker podría controlar uno de los sistemas explorando la vulnerabilidad del sistema de seguridad, pero se evitan daños mayores ya que sólo quedan abiertos aquellos puertos realmente necesarios para la aplicación.

Este sistema tiene una desventaja: queda completamente impotente para frenar los ataques que se realicen a nivel de aplicación web ya que no reconocen como legales o ilegales las entradas (inputs) desde el punto de la aplicación.

A diferencia de las aplicaciones cliente-servidor, en el caso de las aplicaciones web, el código fuente es transferido al PC del usuario, pudiendo leerse e intercambiarse por cualquiera. De allí que sea muy sencillo enviar – como parte de la solicitud al servidor- código fuente alterado, URL modificada o intento de ataque en el campo de entrada que será procesado sobre el servidor objetivo.

((La capa de lógica empresarial toma entrada desde el nivel de la presentación y efectúa un trabajo sobre la misma y devuelve el resultado a la capa de presentación))

Por ejemplo, si un hacker logra burlar un comando SQL en el campo de entrada via Internet hasta el servidor de aplicaciones, este comando llegaría a la base de datos de forma perfectamente legal mediante una conexión permitida por el filtro de paquete. De esta forma no se violaría ninguna regla pero la compañía seguiría siendo vulnerable a potenciales ataques.

La actualización de aplicaciones web consiste habitualmente en diversos niveles llamados arquitectura multicapa (arquitectura n-tier). Suelen ser tres niveles bien diferenciados, el nivel de la presentación, el de lógica empresarial y el de acceso a datos. La capa de presentación ofrece facilidad para generar entradas y mostrar resultados.

La capa de lógica empresarial toma entrada desde el nivel de la presentación y efectúa un trabajo sobre la misma (posiblemente con la ayuda del nivel de acceso a datos) y devuelve el resultado a la capa de presentación. El nivel de acceso a datos proporciona un almacenamiento no volátil de datos susceptibles de ser solicitados o actualizados por la capa de lógica. La mayoría de las tecnologías (ASP, J2EE, PHP, etc) utilizadas para crear aplicaciones web funcionan en su mayoría como páginas HTML ejecutables más que estáticas. Ver la Figura 2.

En un principio cualquier usuario remoto puede ejecutar el código en el servidor web mediante entrada definida por el mismo. El refuerzo del servidor web no ofrece ninguna mejora en este punto. Una solución clara para prevenir este tipo de ataques consistiría en una programación segura de la aplicación web.

No obstante, en la práctica sólo se llevan a cabo controles rudimentarios. De la misma manera, elementos como cookies, cabeceras http, información URL o campos ocultos en el código fuente HTML son a menudo ignorados. Esto significa que el código puede contener y de hecho contiene serias vulnerabilidades capaces de permitir una inyección SQL, codificación cruzada, robo de cookies, alteración de parámetros o inyección de comandos.

Reingeniería o sacar partido a un mal trabajo

Dado lo anterior, las organizaciones no pueden confiar en la seguridad del código. Es interesante preguntarse por qué. Depende de una variedad de razones, pero la más importante de todas ellas es la falta de conocimiento de técnicas exhaustivas de ataques a nivel de aplicaciones sumada a la complejidad y alto coste – tanto económico como de tiempo- que ostentan los códigos de seguridad.

Los desarrolladores tienden a concentrar sus esfuerzos en la prioridad número uno: la aplicación tiene que ser capaz de llevar a cabo la tarea para la que ha sido diseñada. Con la compra de nuevas aplicaciones, las compañías suelen realizar una auditoría sobre sus aplicaciones web para determinar el nivel de vulnerabilidad tras la nueva adquisición. En este sentido la conclusión suele ser unívoca: la empresa es vulnerable. ¿Qué se puede hacer al respecto?

[(La re-ingeniería es una de las opciones, pero su desventaja es el tiempo que conlleva retrasando lo programado hasta varios meses y el coste económico que supone. Sin duda, no es la mejor manera de trabajar ni para el Director TI o un CIO)]

La re-ingeniería es una de las opciones, pero su desventaja es el tiempo que conlleva retrasando lo programado hasta varios meses y el coste económico que supone. Sin duda, no es la mejor manera de trabajar ni para el Director TI o un CIO.

Hay que buscar por tanto soluciones alternativas a la par que efectivas. Ya que los sistemas operativos no son intrínsecamente seguros en cuanto al código, la vía correcta para incrementar la seguridad es o al menos debe ser Firewall de Aplicaciones Web (WAF) en la mayoría de los casos.

Esta tecnología se integra desde el frente de las aplicaciones web a la red y es muy superior a los firewalls clásicos. La diferencia estriba en que los WAFs son capaces de distinguir entre varios campos de entrada, valores parametrales o cookies de aplicaciones individuales y además pueden soportar varias aplicaciones web al mismo tiempo.

¿Qué pedirle a un Firewall de aplicaciones Web?

Los firewalls de aplicaciones web han de comercializarse con una ‘lista negra’ predefinida de códigos de ataques más comunes, así como los fabricantes tendrían que ofrecer un servicio de actualización automático. Es importante que la tecnología seleccionada incluya la función de excluir entradas de campo individuales desde el propio registro para prevenir los positivos falsos, sería el caso de querer permitir el código HTML entrante o la escritura en determinadas aplicaciones web como por ejemplo los foros técnicos de discusión.

Una opción de configuración avanzada para el administrador sería una ‘lista blanca’ con entradas de campo permitidas y todo el resto prohibido. Esta configuración proporciona una mayor protección, defendiendo también de los ataques conocidos como Zero Day. Idóneamente, un buen WAF debe incorporar una combinación de sendos enfoques negativo y positivo de seguridad lógica.

Partiendo de la base del enfoque positivo, el verdadero reto de WAF radica en su capacidad de leer e interpretar la aplicación web, combinando las consideraciones estáticas y dinámicas para formar una política realmente eficaz. La principal diferencia entre ambos enfoques consiste en que la política dinámica es generada durante el tiempo de ejecución, mientras la política estática se constituye de modo previo.

Así, por ejemplo, gracias a la política dinámica el administrador define –durante la instalación- los puntos de entrada válidos (páginas) en el WAF. Si el usuario accede a una página de entrada, todos los links y parámetros del código HTML de respuesta son añadidos al instante a la política dinámica que existe exclusivamente en la memoria y que no puede mostrarse en detalle para por ejemplo una auditoría de seguridad.

Desgraciadamente esta opción no puede utilizarse para aplicaciones complejas en Javascript por el lado del usuario porque permite crear la URL solicitada con sus parámetros, lo que a su vez exige al administrador crear una regla de excepción para definir la URL adecuada. Existen algunos casos problemáticos del uso de Javascript del cliente con la política dinámica, así que el variante estático es el más utilizado en la práctica.

En este caso, el administrador construye una norma ya sea de forma manual o automática con antelación, permitiendo ver con transparencia cada regla o definición realizada, hecho de suma importancia en algunas ocasiones, tal como en el caso de una auditoría de seguridad.

Otra de las características significativas del WAF es la capacidad de configurar la ruta de navegación para controlar el cómo y desde dónde se puede acceder a una página específica. Por ejemplo, si se define que el objeto z.html es accesible solamente si el usuario accede previamente a y.html, el WAF podría bloquear la solicitud directa a z.html.

Esto se denomina Control de Flujo Selectivo (Selective Flow Control). La mayoría de los WAFs pueden comprobar si un valor estático en una solicitud HTML ha sido modificado por un hacker. No obstante, el WAF tiene que ser capaz de proteger a los valores dinámicos – generados en el servidor- que estén siendo atacados o modificados. Este valor dinámico, generado durante el tiempo de ejecución de la aplicación, puede darse bien en la URL o en los campos ocultos.

La modificación de este valor – relativamente sencilla de llevar a cabo- da como resultado un precio más bajo en la cesta de compra de un producto o la posibilidad de acceder a otros datos de los usuarios sin necesidad de introducir el nombre de usuario o contraseña. Ver la Figura 3.

Las aplicaciones utilizan a menudo algoritmos débiles para la generación de la sesión ID, que se realiza de forma dinámica en el servidor y es utilizado como un claro identificador para el usuario. Si el atacante consigue entrar en la sesión del otro usuario, puede hacerse con sus datos sin necesidad de saber el nombre del usuario y su contraseña. El WAF debe ser capaz de proteger de este tipo de ataques extrayendo por ejemplo el valor de la respuesta previa para su comprobación en la posterior solicitud.

Otra de las importantes características del WAF es la capacidad de comprobar los cookies. Un WAF eficaz tiene que saber detectar cuando un cookie ha sido modificado de forma involuntaria (el denominado Cookie Poisoning), previniendo todas aquellas solicitudes adjuntadas a la aplicación web con el fin de parar a cualquier atacante que intente acceder a la sesión de la aplicación de otro usuario.

Una variable para el WAF puede utilizar los nombres y el contenido de todas ls cookies de la aplicación, resumirlos y guardarlos en una cookie adicional que también puede estar encriptada. Esta cookie de sesión adicional existe solamente dentro de la memoria del cliente.

Finalmente, la mayoría de WAF funciona a modo de un servidor Proxy, teniendo así la capacidad de terminar la conexión y analizar la solicitud HTTP del cliente en base a la política establecida. De acuerdo con esto, el WAF abre una conexión completamente nueva para enviar la solicitud http al servidor Web o al balanceo de carga. Ver la Figura 4.

Algunos fabricantes combinan las funciones de gestión de aplicaciones como la gestión del tráfico, compresión, caching o la aceleración SSL con la seguridad de aplicaciones (WAF) en el mismo hardware del dispositivo. Esto trae beneficios reflejados en el rendimiento, facilidad de gestión y ahorro de costes.

¿Por qué necesitas un WAF?

Hasta el momento, hemos comprobado que las aplicaciones web son vulnerables y hemos visto también lo que puede hacerse para proteger a las aplicaciones de estas vulnerabilidades. En muchos casos esto puede no resultar suficiente para impulsar una definición de políticas adecuadas, aunque cabe destacar que las cosas están cambiando.

Recientemente las principales emisoras de tarjetas de crédito (Mastercard, Visa, etc) pertenecientes al Consejo de Estándar de Seguridad PCI (Payment Card Industry) han desarrollado un conjunto de 12 requisitos para mejorar la seguridad del procesado de datos de cuentas en las transacciones electrónicas. Asimismo, el requisito 6.6 del PCI DSS establece que las aplicaciones web tienen que estar protegidas ante ataques conocidos ya sea mediante revisión de código de aplicaciones por compañías especializadas en seguridad o bien mediante instalación de firewall de aplicaciones.

El no cumplimiento de esta norma puede llevar a retirar a las entidades que procesen transacciones electrónicas esta capacidad. En el caso del sector bancario y retail esto podría suponer quedar fuera del negocio, de allí que la cuestión de seguridad de aplicaciones realmente cobre importancia. DDJ

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.