Diseño de seguridad de aplicaciones de escritorio y móviles de Web 2.0

La mayoría de los ataques intentados son dirigidos a aplicaciones web. Estos ataque se enfocan en las vulnerabilidades más comunes, que incluyen cross-site scripting, inyección SQL, manipulación de parámetros, envenenamiento de cookies y fugas de información. Las defensas de perímetro tradicionales, tales como firewalls y sistemas de detección de intrusos, no prevendrán este tipo de ataques, ya que estos explotan vulnerabilidades de programa. Este artículo describe las vulnerabilidades y medidas preventivas posibles más comunes y explica el valor del escaneo de seguridad automatizado en el proceso de desarrollo para producir aplicaciones seguras.

Cesar E. Santiago, Software Engineer, IBM

Photo of Cesar E. SantiagoCesar Santiago ha sido Ingeniero de Software de IBM desde 1999. En los últimos seis años, ha sido parte de la organización WebSphere como desarrollador de seguridad de servicios web y como punto focal de seguridad para el equipo de Paquete de Dispositivos de Web 2.0. Vive en Austin, Texas.



Maryann Hondo, Senior Technical Staff Member, IBM

author photoMaryann Hondo es miembro sénior del personal técnico en IBM WebSphere Technology Institute, con un enfoque en seguridad y computación en nube híbrida. Actualmente trabaja en Seguridad para Dispositivos Móviles y anteriormente trabajó en el equipo DataPower de IBM y en la organización de servicios empresariales, con un enfoque en la habilitación SOA para la seguridad. Maryann es coautora de las especificaciones WS-Security, WS-Trust, WS-SecureConversation, WS-Policy y WS-Federation. Se unió a IBM (Lotus) en 1996, trabajando en seguridad Java, PKIX y Lotus e-Suite. Su trayectoria previa a IBM incluye trabajar para HP en DCE e inicio de sesión único basado en PKI, trabajando para Digital en un sistema operativo B1/CMW, y para AT&T Bell Labs, trabajando en el sistema operativo B2 UNIX



01-08-2011

Los controles de acceso, firewalls, sistemas de detección de intrusos y sistemas de prevención de intrusiones constituyen una parte integral de la seguridad de aplicaciones al proporcionar una defensa de perímetro. Sin embargo, estos mecanismos no previenen en última instancia los ataques a aplicaciones web. Ya que estas aplicaciones son basadas en web, la comunicación con las aplicaciones por los usuarios web permite ataques directos a aplicaciones que evitan las protecciones de perímetro de seguridad establecidas. Los atacantes saben esto, y por ello los ataques directos a aplicaciones web constituyen la mayoría de los ataques intentados.

Para balancear la ecuación, los desarrolladores de aplicaciones deben estar conscientes de las estrategias de defensa contra los ataques. Deben también considerar atender algunos de los factores que contribuyen a un número de ataques:

  • La mayoría de los desarrolladores de aplicaciones no son expertos en seguridad y probablemente no conocen la mayoría de las vulnerabilidades.
  • Muchos no conocen las buenas prácticas de seguridad para desarrollo de aplicaciones web.
  • Frecuentemente se le da prioridad a la funcionalidad y las preocupaciones de seguridad son atendidas después como soluciones adaptadas.
  • El entorno en el que las aplicaciones web son implementadas tiene un alto rango de cambio, incluyendo actualizaciones al código de aplicación mismo así como a la infraestructura. Algunos de estos cambios no son investigados o probados por los profesionales de seguridad apropiados.

Estos factores nos llevan a pasos que todo desarrollador de aplicaciones puede tomar para escribir un mejor código.

  1. Estudiar.
  2. Buscar patrones establecidos.
  3. Integrar pruebas en su plan de desarrollo.
  4. Informar errores a tiempo.

Este artículo contribuye a la educación de desarrolladores e implementadores en algunas de las vulnerabilidades de aplicaciones web más comunes que afectan aplicaciones de Web 2.0. También proporciona una introducción a problemas de seguridad exclusivos para dispositivos móviles.

Vulnerabilidades web comunes

Las aplicaciones web móviles son vulnerables a muchas de las mismas vulnerabilidades que son normalmente asociadas con aplicaciones web de escritorio. Un recurso para aprender más sobre vulnerabilidades y medidas preventivas es el Proyecto Top 10 en el sitio web de Open Web Application Security Project (OWASP) (vea Recursos para obtener un enlace).

Las subsecciones a continuación describen muchas de las principales vulnerabilidades que los desarrolladores deben entender.

Cross-site scripting

En este común ataque, código malicioso es inyectado en un sitio web auténtico. Si la entrada de una solicitud HTTP puede llegar al HTML resultante de una página, está abierta a este ataque.

Por ejemplo, un servicio acepta un parámetro llamado image para recuperar una imagen del sistema de archivos para realizar algo de procesamiento:

http://somedomain/myImageProcessor?image=myimage.jpg

Un atacante podría intentar explotar esta aplicación al insertar código JavaScript en el parámetro image. La intención es explotar el manejo de errores defectuoso. Si se puede generar un mensaje de error que incluya el script malicioso, el atacante aprovecharlo:

http://somedomain/myImageProcessor?image=myimage.jpg
<script>...código malicioso ...</script>

Si el mensaje de error regresa los contenidos del parámetro image sin filtrar, el código adjunto en las etiquetas <script> se ejecuta. El script podría acceder potencialmente a cookies locales de la página web atacada e incluso alterar el contenido de la página presentada. Esta vulnerabilidad puede ser explotada enviando enlaces contaminados por e-mail o incluyéndolos en páginas web maliciosas.

Este concepto está demostrado el sitio web Altoro Mutual, que es un sitio de demostración para las posibilidades de escaneo de vulnerabilidades de aplicaciones de IBM® Rational® AppScan® Standard Edition (ver el enlace en Recursos).

Figura 1. Sitio de demostración Altoro Mutual AppScan
Sitio de demostración Altoro Mutual AppScan

Como muestra la Figura 2, buscar el término "pineapples" le muestra que los términos de búsqueda son mostrados al usuario con resultados, sin importar si hay resultados o no.

Figura 2. Buscar resultados siempre muestra el término de búsqueda
Buscar resultados siempre muestra el término de búsqueda

Este resultado es una pista de que la aplicación es susceptible a un ataque de cross-site scripting. La Figura 3 muestra el resultado cuando el término de búsqueda <script>alert('attack')</script> es ingresado como término de búsqueda. El código de script es retornado en el resultado de búsqueda, el código es ejecutado y una ventana de alerta es mostrada.

Figura 3. Ingresar "JavaScript" como un término de búsqueda resulta en la ejecución de JavaScript
Ingresar

Medidas preventivas

Para prevenir cross-site scripting (XSS):

  • No muestre entradas no confiables al usuario.
  • Tome medidas para el saneamiento de entradas y salidas que eliminen código malicioso, tales como el filtrado o white listing (definiendo qué entrada es permitida y no permitiendo nada más).
  • Codificar la salida para prevenir la ejecución de navegador.

Para Altoro Mutual, un simple arreglo sería no regresar la búsqueda.

Para ver una conversación más profunda sobre cross-site scripting y prevención, lea el artículo de developerWorks® titulado "IBM Rational AppScan: Cross-site scripting explicado", así como la página de capacitación de Open Web Application Security Project (OWASP) sobre cross-site scripting (vea Recursos para obtener enlaces)

Inyección de SQL

Este ataque también se enfoca en explotar las debilidades en solicitudes y tiene como objetivo insertar una entrada de SQL en los campos de entrada de una aplicación web. Un atacante que puede insertar consultas como parte de un campo de entrada puede evitar los mecanismos de autenticación de un sitio web y ganar acceso a la base de datos. Este ataque es uno de los más explotados, junto con cross-site scripting

Este ejemplo muestra cómo un procedimiento de inicio de sesión pobremente construido es explotado usando inyección SQL:
Una aplicación web solicita el nombre de usuario y contraseña para iniciar sesión, y la sentencia SQL está construida de la siguiente forma:

String query = "SELECT * FROM users WHERE user ='"username+"' AND password ='"passwd"'";

Las variables username y password no están saneadas en ninguna forma y están asignados los valores ingresados por el usuario en la aplicación. Esto permite que un usuario malicioso ingrese algo como esto como username:

anything' OR 1=1 --

La contraseña puede ser cualquier cosa. En este caso, asuma que es un asterisco: *.

Cuando el código sustituye las variables username y password para esta entrada, la consulta construida es:

SELECT * FROM users WHERE username ='anything' OR 1=1 -- AND password ='*'

Esta sentencia toma el requisito de contraseña e inserta la condición 1=1, que es siempre verdadera. El atacante será validado como un usuario válido aunque sus credenciales no fueron proporcionadas.

Este ataque es demostrado por la aplicación web de Altoro Mutual (ver también la Figura 4). Vaya a la página de inicio de sesión e ingrese un nombre de usuario de anything' OR 1=1 -- y cualquier carácter como contraseña otorga el acceso a la aplicación como un administrador (Figura 5). Esta cuenta tiene el poder de manipular otras cuentas de usuario.

Figure 4. Un intento de iniciar sesión con un nombre de usuario arbitrario y un fragmento de SQL como contraseña
Figure 4. Un intento de iniciar sesión con un nombre de usuario arbitrario y un fragmento de SQL como contraseña
Figura 5. El atacante inicia sesión como administrador después de ejecutar un ataque de inyección SQL
El atacante inicia sesión como administrador después de ejecutar un ataque de inyección SQL

Como el cross-site scripting, este ataque es el resultado de una entrada pobre o inexistente de saneamiento y validación.

Medidas preventivas

Para prevenir este ataque:

  • Trate todas las entradas del usuario como no confiables.
  • Tome medidas para sanearlas, tales como filtrado o white listing.

En el caso de Altoro Mutual, una posible solución es filtrar cualquier carácter no alfanumérico que venga de los campos Username y Password.

Para obtener más información sobre la inyección SQL y las medidas preventivas posibles, lea la página de capacitación de OWASP sobre Inyección SQL (vea Recursos)

Fugas de información

Un atacante determinado puede analizar una aplicación para tratar de identificar las debilidades. Por ejemplo, un atacante puede extraer la información en distintas formas:

  • Explorar la aplicación manualmente para encontrar directorios ocultos
  • Forzar sistemáticamente excepciones para ver si la aplicación da detalles de excepción
  • Buscar comentarios en el HTML que revelen detalles de la infraestructura y comportamiento de la aplicación
  • Ingresar sistemáticamente nombres de usuario para descubrir cuentas existentes

La aplicación de Altoro Mutual sí tiene fugas en los nombres de usuario existentes en el sistema. Por ejemplo, en la Figura 6, ingresar un nombre de usuario y contraseña incorrectos produce este mensaje de error "Login Failed: We're sorry, but this user name was not found in our system. Please try again".

Figura 6. La aplicación declara explícitamente que el usuario no fue encontrado en el sistema
La aplicación declara explícitamente que el usuario no fue encontrado en el sistema

A continuación, el atacante intenta el nombre de usuario jsmith, y la aplicación web de Altoro Mutual emite el siguiente mensaje: "Login Failed: Your password appears to be invalid. Please re-enter your password carefully". De ahí, el atacante aprende que existe una cuenta de usuario llamada jsmith. Con este conocimiento, el atacante puede concentrarse en descifrar la contraseña, quizá tratando de adivinarla con un ataque de fuerza bruta.

Figura 7. La aplicación de Altoro Mutual revela la existencia del nombre de usuario jsmith
La aplicación de Altoro Mutual revela la existencia del nombre de usuario jsmith

En este caso, el arreglo sería producir un mensaje genérico de inicio de sesión que no diga precisamente qué ha fallado, por ejemplo: "Login failed: User name or password invalid. Please re-enter your credentials carefully".

Medidas preventivas

La fuga de información es algo que debe ser considerado en el contexto de la aplicación, y que los desarrolladores tengan conocimiento de esto es la mejor defensa. Con esa meta en mente, existen diversas medidas de mitigación para que los desarrolladores las consideren.

  • Código HTML claro de todos los comentarios que revelen cualquier cosa sobre la aplicación.
  • No mostrar excepciones específicas en el navegador. Si deben ser registradas, almacenarlas en el servidor y mostrar un error genérico.
  • No revelar qué parte de la autenticación ha fallado.
  • También, configurar valores de servidor web y servidor de aplicaciones para prevenir la navegación arbitraria del sitio web y la aplicación.

Esta lista de fugas de ninguna manera es exhaustiva. Busque otras fugas específicas a la aplicación y el entorno de ejecución.

Puede encontrar más información en la página de capacitación de OWASP sobre fugas de información.

Manipulación de parámetros

Este ataque tiene como objetivo manipular los parámetros pasados a una aplicación. Considere una aplicación pobremente escrita que permita al cliente establecer el precio de un artículo a ser comprado. Esta aplicación podría enviar la siguiente solicitud:

http://somedomain/myStore?item=1234&price=$200

Si la lógica empresarial no realiza ningún tipo de doble verificación en el lado del servidor, un atacante podría cambiar el precio para obtener el elemento a un precio más bajo. Permitir que el precio sea establecido desde el lado del cliente es claramente un error en este caso.

Medidas preventivas

  • Para corregir esta instancia particular, puede cambiar el código para obtener el precio desde una base de datos del lado del servidor, evitando la manipulación de precios.
  • La prevención de este ataque incluye la validación de parámetros y la cuidadosa consideración de la lógica de la aplicación.

Para obtener más información sobre la manipulación de parámetros y las medidas preventivas posibles, lea la página de capacitación de OWASP sobre manipulación de parámetros web (vea Recursos).

Envenenamiento de cookies

Una cookie es información enviada desde el servidor al navegador, almacenada como pares de clave/valor en un archivo de texto o memoria. Su contenido puede ser usado por la aplicación web que la creó. El envenenamiento de cookies sucede cuando el contenido de la cookie es modificado después de la ejecución de una aplicación web. Esto es similar a la manipulación de parámetros.

Medidas preventivas

  • Las medidas preventivas para el envenenamiento de cookies incluyen la validación de parámetros y la inspección cuidadosa de la lógica y el código de la aplicación.
  • También pueden aplicarse mecanismos de seguridad avanzados.
    • Un enfoque común es usar firmas digitales para verificar que el almacenamiento del archivo de texto no ha sido manipulado.
    • Otra medida preventiva es la protección de la cookie al cifrarla durante la transmisión para mitigar el riesgo de alteración y espionaje durante el tránsito.

El envenenamiento de cookies es comentado en la página de OWASP sobre vulnerabilidades de entradas invalidadas (vea Recursos).


Integrando la seguridad en el proceso de desarrollo

La seguridad se está convirtiendo en una parte esencial del desarrollo de aplicaciones web y, por lo tanto, del desarrollo de aplicaciones web móviles. Muchas organizaciones se preocupan especialmente por entregar funcionalidad. Sin embargo, considere que el costo de readaptar un arreglo de error de seguridad no es trivial. Por lo tanto, es inteligente incluir revisión y pruebas de seguridad como una parte esencial del proceso de desarrollo.

La seguridad es más efectiva cuando es integrada durante todo el proceso de desarrollo, desde el diseño hasta la implementación.

Fase de diseño
Durante el diseño, identifique qué información debe ser protegida, cuáles son los riesgos y qué medidas preventivas están disponibles. De ser posible, incluya a los expertos en seguridad de TI de la organización en la conversación y en las decisiones de estas primeras etapas. Esto disminuye las posibilidades de que surjan vulnerabilidades después en el ciclo de desarrollo. El descubrimiento tardío lleva a soluciones no óptimas y readaptadas cuya atención es costosa. Identifique escenarios prácticos para pruebas en la fase de diseño. Esto ayudará a establecer un proceso integrado para prueba durante todo el ciclo de vida del desarrollo. Las pruebas de seguridad incrementales (tales como las pruebas de penetración) realizadas en la fase de implementación ayudan a una organización a optimizar los conjuntos de habilidades necesarios para asegurar un buen desarrollo de aplicaciones.
 
Fase de desarrollo
Capacite a los desarrolladores sobre las vulnerabilidades más comunes y prácticas de codificación segura. En las revisiones de código, atienda los problemas de seguridad e incluya a los profesionales de seguridad de la organización. Implemente pruebas de seguridad, revíselas e inclúyalas en cualquier suite de pruebas automatizadas. Planifique que el equipo de desarrollo esté disponible para atender problemas de seguridad encontrados durante la revisión y pruebas del código.
 
Fase de implementación
Pruebe por completo la aplicación terminada en un entorno de preproducción. Esta fase de pruebas puede incluir pruebas de penetración en la aplicación por parte de un equipo externo o de herramientas de escaneo de seguridad automatizadas. La práctica de gobierno de TI normalmente indica el criterio para la aprobación final.
 
Fase de gestión
Después de la implementación, supervise periódicamente la aplicación y su entorno para encontrar posibles ataques y vulnerabilidades utilizando herramientas de escaneo, pruebas de penetración y auditoría de registros. Establezca un proceso claro para modificar de manera segura el entorno y aplicar parches para la aplicación.
 

Automatización de pruebas de seguridad en el proceso de desarrollo

Cuando una práctica es establecida, la automatización es clave para la creación de un proceso de seguridad repetible y consistente durante todo el ciclo de desarrollo. Los productos de IBM Rational AppScan proporcionan herramientas que pueden explorar el código para ayudar a los desarrolladores a encontrar vulnerabilidades. Las herramientas de escaneo automatizadas también pueden ser reutilizadas después del desarrollo para supervisar las aplicaciones implementadas. Esto mantendrá la aplicación web implementada debidamente supervisada y ayudará a detectar fallas de seguridad introducidas inadvertidamente cuando una aplicación o la infraestructura cambian.

La familia de productos Rational AppScan aporta a la automatización de estas actividades durante todas las fases de desarrollo e implementación.

Fase de desarrollo

  • Rational AppScan Source Edition: Para el desarrollador de aplicaciones, esta herramienta proporciona análisis white box del código, de forma que los desarrolladores pueden identificar problemas en la etapa más temprana del desarrollo. También proporciona información a los desarrolladores sobre las posibles vulnerabilidades encontradas y consejos de remediación.
  • Rational AppScan Tester Edition: Para equipos de control de calidad (QA), esta herramienta facilita la integración y automatización de pruebas de seguridad en el proceso de QA. Los sujetos de pruebas pueden añadirla a sus entornos de pruebas existentes para integrar las pruebas de seguridad en pruebas de funcionalidad y rendimiento.
  • Rational AppScan Build Edition: Esta versión soporta la integración del escaneo de seguridad durante el proceso de construcción. Se integra con sistemas de gestión de construcción, tales como Rational® Build Forge®, y también pueden enrutar informes a desarrolladores mediante software de gestión de defectos, como Rational® Clear Quest®.

Fase de implementación

  • Rational AppScan Standard Edition: Para el auditor de seguridad, esta versión realiza pruebas black box de una aplicación implementada. El auditor puede especificar la URL de una aplicación existente (de preferencia en un sistema de preproducción), y la herramienta explora la aplicación y busca vulnerabilidades conocidas. Una lista priorizada de vulnerabilidades es creada, junto con detalles de cada una y posibles medidas de mitigación. La creación de informes personalizados para la distribución a los equipos de desarrollo y gestión está soportada.
  • Rational AppScan Enterprise Edition: Esta es una herramienta de usuarios múltiples basada en web para equipos que deben escalar el escaneo de aplicaciones en toda la empresa y de manera centralizada. Al igual que Rational AppScan Standard Edition, explora las aplicaciones existentes y genera informes con listas priorizadas y tareas de remediación. Puede ayudar a distribuir la responsabilidad para remediar los problemas.

Vea Recursos para obtener más información sobre la familia de productos Rational AppScan y un enlace a la guía IBM® Red guide® sobre cómo la familia de productos Rational AppScan puede ayudar a automatizar e integrar la seguridad en el proceso de desarrollo.


Retos exclusivos de acceso a aplicaciones web desde dispositivos móviles

Muchos de los riesgos para las aplicaciones y dispositivos son una extensión de las vulnerabilidades actuales de aplicaciones de escritorio. Las prácticas actuales para el control de identidad y acceso están más allá del ámbito de este artículo, pero las áreas estándar cubiertas por el gobierno de aplicaciones web incluyen:

  • Escaneo de aplicaciones para encontrar vulnerabilidades conocidas
  • Control de acceso
  • Identificación y autenticación de usuario
  • Identificación y gestión del punto final
  • Malware

Lea el documento de los IBM® Redbooks® citado en Recursos para aprender más sobre cómo la familia de productos de IBM puede integrar la seguridad. También, más información sobre la familia de productos de IBM® Tivoli® puede ser encontrada en la página web de IBM Web Application Security Solutions.

Los dispositivos móviles presentan un conjunto de retos adicional debido a su naturaleza altamente personal y portable. Los dispositivos móviles son más fáciles de extraviar. El teléfono inteligente que es dejado en un taxi o un avión porque se cayó del bolso es un escenario muy común. Los teléfonos inteligentes también son el objetivo de robos debido a su tamaño pequeño. Por estas razones, se deben establecer prácticas de seguridad adicionales para aplicaciones web que son accesibles a través de dispositivos móviles.

Las áreas adicionales de gobierno corporativo que deben atenderse cuando se implementan dispositivos móviles incluyen:

  • Autenticación de factores múltiples. Combine dos métodos de autenticación, por ejemplo, una contraseña y un dispositivo lector de huella dactilar si está disponible en el dispositivo.
  • Control de acceso de grano fino. Se debe permitir acceso a los usuarios a los recursos exactos que necesitan para hacer su trabajo, no más. Cualquier mecanismo de control de acceso debe ser tan granular como sea posible.
  • Acceso restringido: Permita el acceso a recursos de internet desde el internet con Redes Privadas Virtuales (VPN).
  • Cifrado de datos. Iguale las posibilidades del dispositivo con los requisitos de datos confidenciales.
  • Gestión. Si la información confidencial es permitida, entonces una limpieza segura del dispositivo es aconsejable para dispositivos perdidos o robados.

Resumen

Las aplicaciones Web 2.0 para dispositivos de escritorio y móviles comparten muchos problemas de seguridad y, por lo tanto, muchas medidas preventivas. Los desarrolladores deben capacitarse sobre las vulnerabilidades más comunes y atenderlas durante todo el ciclo de desarrollo. También se requiere el escaneo continuo automático de vulnerabilidades durante el desarrollo y la implementación para mantener las aplicaciones aseguradas. Los dispositivos móviles presentan su propio conjunto exclusivo de retos debido a su naturaleza altamente personal y portable. Planifique cómo mantener los datos seguros en caso de que el dispositivo sea robado o extraviado antes de que implemente soluciones móviles.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=746576
ArticleTitle=Diseño de seguridad de aplicaciones de escritorio y móviles de Web 2.0
publish-date=08012011