Las aplicaciones son vitales para muchas organizaciones, cada vez más y más dependen de ellas para mantener un crecimiento continuo. Con el mayor uso de las tecnologías y el incremento del número de teléfonos inteligentes y usuarios de PDA (asistentes digitales personales), muchas aplicaciones han sido movidas a estos dispositivos como una App. Y con la popularidad de implementaciones basadas en la nube, el concepto de software como un servicio (SaaS) se ha convertido en la tendencia actual.

Cada vez más negocios cuentan con aplicaciones basadas en la Web, por lo que el desarrollo e implementación de aplicaciones de este tipo se ha vuelto más popular. Los negocios requieren asegurar una protección adecuada de la información crítica dentro de las aplicaciones, tanto de usuarios internos como externos, para infundir confianza y proporcionar seguridad a los clientes y personas interesadas (stakeholders). La seguridad de aplicaciones está ganando la atención de la alta gerencia en muchas organizaciones, y con la creciente popularidad de los dispositivos móviles y los servicios de cómputo en la nube, dicha seguridad ha cobrado mayor relevancia, dado que las mismas funcionalidades están ahora siendo replicadas en App móviles que pueden ser fácilmente descargadas por los usuarios e incluso por gente malintencionada.

Este artículo está dirigido a las aplicaciones de negocio y su seguridad. A pesar de que existen muchas herramientas, incluyendo programas gratuitos (freeware) que pueden detectar vulnerabilidades, especialmente para aplicaciones Web, este texto está enfocado en la valoración manual (no basada en herramientas) para cualquier tipo de aplicaciones de negocio y en cómo sacar mejor provecho de los esfuerzos al respecto.

Retos y escenarios clave en los que la evaluación manual de la seguridad de aplicaciones es útil:

  • Se prohíben herramientas en el ambiente de producción. La organización puede tener una política que prohíba el uso de herramientas de hackeo y penetración en el ambiente de producción, o no está dispuesta a correr el riesgo por los cambios accidentales que pudieran generar esas herramientas.
  • Se tiene una aplicación antigua (“legacy”) o que no está basada en la Web. La mayoría de las herramientas de análisis y evaluación de la seguridad de aplicaciones son específicamente para ambientes Web. Cuando se enfrenta una aplicación de tipo legacy o no basada en Web, lo mejor es utilizar técnicas manuales de evaluación de seguridad.
  • Lo que se busca es identificar fallas lógicas del negocio. Las herramientas automatizadas, especialmente las de evaluación de seguridad de aplicaciones, no ayudan a localizar errores en la lógica del negocio. Por ejemplo, PCI DSS exige que los datos sensibles de una tarjeta de crédito, como el número de dicha tarjeta, no deben ser visibles en texto plano para ciertos usuarios de la aplicación. Ahora bien, si esta información es cifrada o enmascarada, es probable que no sea fácil validarla utilizando herramientas automatizadas. De manera similar, las fallas en aplicaciones producidas por errores lógicos que pudieran conducir a fraude, es mejor localizarlas con un enfoque manual.

.

¿Cuáles son las limitaciones de la evaluación manual de seguridad de aplicaciones?

  • Un enfoque manual será una tarea tediosa y costosa si las aplicaciones corren en un gran número de páginas, pantallas, formatos y opciones en menús.
  • La evaluación manual de seguridad de aplicaciones depende mucho de las habilidades de la persona que lleva a cabo la tarea. A diferencia de las herramientas automáticas en las que los patrones o firmas de ataque pueden ser preconfigurados e identificados automáticamente, las técnicas manuales realmente involucran la comprensión y localización de las vulnerabilidades en la aplicación.
  • Puede haber el riesgo de que algunos problemas de seguridad en las aplicaciones no sean detectados debido a error humano o a falta de tiempo.

.

¿Cómo obtener el mayor beneficio de la evaluación manual de seguridad de aplicaciones?

No hay un número limitado de pruebas que puedan ser llevadas a cabo en una aplicación; sin embargo, estas son algunas de las técnicas más útiles:

  1. Dedicar tiempo de calidad para comprender la información crítica del negocio procesada por la aplicación.

Para los usuarios del negocio no importa cuántas vulnerabilidades y problemas técnicos se observen y reporten en una aplicación, si dicho reporte no demuestra cuál información crítica del negocio está realmente en riesgo. En nuestra experiencia práctica, dedicar tiempo de calidad a esta actividad ayuda mucho a mejorar la valoración/evaluación de la seguridad. Entrevistar usuarios del negocio y utilizar diagramas de flujo de datos facilita la identificación de los escenarios más probables en los que la confidencialidad, integridad y disponibilidad de dicha información podría ser un gran problema. De la misma manera, es importante comprender si las aplicaciones en cuestión reciben alguna información de otras aplicaciones o como entrada de algún archivo plano u otros mecanismos.

  1. Buscar manuales de usuarios y otra documentación relacionada con la aplicación.

Los manuales podrían explicar cómo la aplicación puede utilizarse desde el punto de vista de un usuario. Si se tratara de una aplicación compleja, se tendría suerte si se encontrara un manual de administración del sistema. Si la aplicación ha sido desarrollada “en casa”, se deberían requerir diversos documentos creados durante el ciclo completo de vida del desarrollo de software. La clave a resaltar es que cuando se están revisando estos documentos se está buscando información útil que ayude a comprender ampliamente el diseño de seguridad de la aplicación o sus componentes arquitectónicos.

  1. Verificar si existe un escenario de prueba (test setup) para la aplicación evaluada.

Aunque usted realmente no va a evaluar el escenario de prueba, lo he encontrado muy útil en mis evaluaciones manuales, en las que las herramientas no están disponibles, ya sea porque se trata de un sistema legacy o porque la aplicación no está basada en la Web.  Por su naturaleza misma, dado que se trata de un escenario de prueba, se puede arriesgar ingresando basura y elaborar tantas pruebas negativas como se desee.

Si usted considera necesario familiarizarse aún más con la aplicación, en cualquier momento puede solicitar ayuda de los usuarios del negocio para hacer una rápida, pero completa revisión de la aplicación. Por ejemplo, en una de nuestras evaluaciones identificamos un escenario de bypass de autenticación, en el que a un usuario normal le fue proporcionada una pantalla opcional para cargar un archivo y esta pantalla estaba destinada únicamente a usuarios privilegiados. El equipo de desarrollo del cliente no estaba convencido de que los usuarios normales pudieran cargar archivos, pues esto había sido programado únicamente para usuarios privilegiados. Sin embargo, cuando demostramos exitosamente la posibilidad de dicha situación en el escenario de prueba, captó la atención del equipo de desarrollo.

  1. Integre el enfoque basado en riesgos en su evaluación manual de seguridad de aplicaciones.

Encontramos muy útil el enfoque basado en riesgos en todos nuestros proyectos de evaluación manual de seguridad de aplicaciones.  En este tipo de enfoque, se pueden identificar los riesgos de la aplicación en términos de amenazas/vulnerabilidades y su correspondiente probabilidad e impacto, y las áreas de alto riesgo resultantes son las primeras en ser evaluadas con mayor énfasis. Por ejemplo, si se trata de una aplicación con requerimientos regulatorios de mucho peso, entonces el violar alguno de esos requerimientos regulatorios sería un área de alto riesgo. De modo similar, si la aplicación está procesando información de identificación personal o información sensible, entonces todos esos módulos dentro de la aplicación, los cuales administran las entradas, procesamiento, almacenamiento y salidas que tienen que ver con esa información son áreas de alto riesgo y deben evaluarse primero.

En una de nuestras evaluaciones de seguridad de una aplicación desarrollada “en casa”, utilizada para el procesamiento de tarjetas de débito y de datos de tarjetas ATM, al utilizar el enfoque basado en riesgos se pudo identificar la existencia de puntos críticos dentro de la aplicación, en la cual la confidencialidad de los datos se estaba perdiendo, de tal manera que realizamos pruebas enfocadas a la aplicación para demostrar cómo la información confidencial se encontraba disponible por un muy corto tiempo para otros usuarios no autorizados.

  1. Cuente con una lista de revisión básica de la evaluación de seguridad y adáptela a la aplicación específica.

Es recomendable contar con un checklist básico, el cual se deberá probar para cada aplicación y, con base en su propio estudio de la aplicación específica, podrá adaptarla. Si se trata de una aplicación basada en Web, entonces podrá encontrar guías excelentes disponibles en el sitio Web de OWASP, las cuales pueden utilizarse para llevar a cabo las pruebas e integrarse al checklist básico. En cambio, si se trata de una aplicación no basada en la Web, entonces se puede iniciar con un checklist básico, como el mostrado a continuación, y adaptarlo a sus propias necesidades:

  Validación de entradas y salidas
Núm. Descripción Sí / No / NA Observaciones
1 ¿La validación de entrada se lleva a cabo cada vez que los datos son recibidos por una función y sus parámetros?    
2 ¿La validación acepta las entradas diversas, basadas en el tipo de datos, formatos y longitudes máximas/mínimas?    
3 ¿La aplicación valida las entradas tanto del lado del cliente como del lado del servidor?    
4 ¿La aplicación valida SQL Injection y otros tipos de ataques de  entradas?    
5 ¿Todas las salidas visibles están basadas en los roles de usuarios, según se definen en la aplicación?    
  Autenticación y autorización
1 ¿Los roles y cuentas de usuario utilizadas en la aplicación han sido configuradas considerando el principio de mínimo privilegio?    
2 ¿La aplicación restringe el número de intentos fallidos de acceso?    
3 ¿Existe una política de contraseñas estricta o un mecanismo de autenticación construido dentro de la aplicación?    
4 ¿Los tokens relacionados con autenticación, tales como cookies, se transmiten a través de conexiones seguras?    
5 ¿La información de autenticación está cifrada?    
6 ¿Existe información de autenticación codificada (hard-coded) dentro de la aplicación?    
Almacenamiento seguro
1 ¿Cuáles son los algoritmos de criptografía utilizados por la aplicación para requerimientos de cifrado y hashing? ¿Son estos robustos?    
2 ¿Los datos sensibles se cifran o enmascaran para protegerlos?    
3 ¿Se protegen las copias temporales de datos sensibles contra el acceso no autorizado, y se programa su remoción cuando ya no van a ser utilizados?    
Comunicación segura
1 ¿La aplicación utiliza módulos de criptografía, los cuales refuerzan el uso de algoritmos de seguridad?    
2 ¿La aplicación identifica mecanismos de protección para datos sensibles que son enviados sobre la red (interna y externa)?    
3 ¿Se utilizan mecanismos como SSLv3/TLSv1/SSHv2 (o similares) para proteger cookies y datos sensibles tales como nombres de usuario, contraseñas o datos de tarjetas de crédito, mientras la información se encuentra en tránsito?    
Manejo de errores
1 ¿Existe un enfoque estándar apropiado para estructurar el manejo de excepciones en la aplicación?    
2 ¿La aplicación identifica el nivel de auditoría y almacenamiento (logging) necesario y los parámetros clave para ser almacenados y auditados?    
3 ¿Se asegura que los recursos sean liberados si ocurre un error?    
Administración de sesiones
1 ¿La aplicación genera un nuevo identificador de sesión (session ID) cuando un usuario requiere ser reautenticado en pantallas que involucran acciones sensibles?    
2 ¿Los valores de sesión expiran automáticamente después de un lapso de tiempo predefinido?    
3 Determine las acciones que la aplicación lleva a cabo si ocurre una sesión de ID inválida.    
4 Determine cómo funciona la funcionalidad de log-out o cómo terminan las sesiones de usuarios.    
         

Las organizaciones deben definir sus aplicaciones críticas de negocio y las amenazas del ambiente para una correcta seguridad en dichas aplicaciones. Llevando a cabo evaluaciones internas de seguridad de aplicaciones, pueden integrar prácticas de seguridad en forma temprana en el ciclo de vida de desarrollo de software. Algunas de las aplicaciones son, a veces, creadas con nuevas tecnologías para las cuales las herramientas automatizadas es probable que no se encuentren fácilmente disponibles. Se pueden identificar técnicas efectivas de evaluación para cualquier tipo de aplicación utilizando el enfoque basado en riesgos y siguiendo principios fundamentales para la evaluación de seguridad de aplicaciones, según se ha mencionado arriba. Los resultados son siempre positivos, porque un enfoque solo basado en herramientas no puede reportar riesgos importantes de seguridad de aplicaciones, dado que existen muchos escenarios en los que es necesario contar con los resultados de evaluaciones manuales.

.

[email protected]

.

Referencias:

  1. https://www.owasp.org/index.php/Category:OWASP_Guide_Project
  2. Hacking Exposed: Web Applications 3, by Joel Scambray, Vinvent Liu, Caleb Sima, published by McGraw-Hill Osborne Media, ISBN
  3. http://www.isaca.org/Journal/archives/2004/Volume-4/Pages/Systems-Development-Advice-in-a-Web-enabled-World.aspx
  4. http://www.softwaretestingclass.com/what-is-risk-based-testing-in-software-testing/
  5. http://www.nist.gov/customcf/get_pdf.cfm?pub_id=890097