La Auditoría de Seguridad de una aplicación puede abordarse desde una vertiente de caja negra u otra de caja blanca, en la que se dispone y audita el Código Fuente de la aplicación. La Auditoría de Código Fuente requiere un componente manual capaz de asimilar el contexto de la aplicación para obtener resultados óptimos y esa capacidad es la que ofrece el equipo de Auditoría de Neurosec.

En general, la Auditoría de Código Fuente o Auditoría de Caja Blanca requiere de la colaboración del equipo de desarrollo, nadie mejor que ellos conoce la estructura de la aplicación y puede facilitar el camino en la revisión de código optimizando las zonas de éste que se auditarán. Para desarrollar una auditoría de Código Fuente efectiva es necesario emplear o seguir una metodología reconocida y exhaustiva. Neurosec sigue las pautas marcadas en la OWASP Code Review Guide, aún en producción, pero que pretende ser (al igual que otros documentos publicados por este organismo) una guía o estándar de referencia en este tipo de proyectos.

CARACTERÍSTICAS DEL SERVICIO

El punto clave cuando se audita el código de una aplicación de cierta complejidad o tamaño es conocer el contexto y otras características clave de ésta. El Equipo que realice el proyecto tendrá como meta en esta fase familiarizarse con los siguientes aspectos de la aplicación:

• Código: El lenguaje de programación y las funcionalidades y particularidades de este desde el punto de vista de la seguridad dado que el objetivo del proyecto será definir las mejoras posibles para conseguir implantar unas buenas prácticas en seguridad en desarrollo en ese lenguaje concreto.
• Contexto: Es necesario familiarizarse con la aplicación a revisar. La seguridad que se pretende alcanzar vendrá definida por los requerimientos de negocio de donde se usa la aplicación, qué datos manipula y cuáles serían las consecuencias de un acceso ilegítimo a esta información.
• Audiencia: Puede ser conveniente disponer de la colaboración de usuarios de las aplicaciones que faciliten información sobre la aplicación auditada. Conocer cómo se han implementado controles de seguridad en los aspectos críticos y claves en esta permitirá conocer dónde pueden encontrarse aquellas deficiencias más relevantes.
• Topología: Situación de la aplicación y sus componentes dentro del contexto de la red (en algunos casos se prescindirá de la revisión de estos aspectos).
• Importancia: Es necesario conocer la necesidad de disponibilidad de la aplicación y el efecto de la pérdida de ésta para el negocio.

ÁMBITO DE LAS PRUEBAS

La metodología creada por Neurosec permite llevar a cabo una exhaustiva revisión sobre las aplicaciones auditadas cubriendo los siguientes aspectos de seguridad:

• Autenticación: Se audita que todas las conexiones internas y externas (usuarios y entidades) pasan a través de un apropiado y adecuado sistema de autenticación y asegurar que estos controles no pueden ser sobrepasados; todas las páginas o zonas de la aplicación requieren la autenticación adecuada; aquellos puntos donde se transmiten credenciales o información sensible se emplean POST; que las credenciales se transmiten cifradas; etc.
• Autorización: Se comprueba que se hayan implementado los mecanismos adecuados de autorización; definido claramente los tipos o perfiles de usuario y los derechos de dichos usuarios; se emplea la premisa de “mínimos privilegios”; autorización en cada petición; etc.
• Gestión de Cookies: Se revisa que las cookies no incluyen información sensible; que no se pueden realizar acciones no autorizadas mediante su manipulación; se emplea cifrado y transmisión no segura; los datos se sesión se validan correctamente y la cookie mantiene la menor cantidad de información posible; etc.
• Validación de Datos de Entrada: La auditoría verifica que existen mecanismos de Validación de Datos robustos e incluyen todos los datos que pueden ser modificados por un usuario malicioso como cabeceras HTTP, campos de entrada, campos ocultos, datos de listas, cookies, cabeceras/datos HTTP ; que todas las comprobaciones de validación de datos en el servidor y no en el lado del cliente; que no existen puertas traseras en el modelo de validación; etc.
• Gestión de Errores/Fugas de Información: En este punto se revisa que todos los métodos/funciones que devuelven valores tienen una correcta gestión de errores y devuelven valores comprobados y esperados en condiciones de error. Gestionando excepciones y situaciones de error; que no se devuelven errores del sistema al usuario; la aplicación falla de “forma segura”; etc.
• Registro/Auditoría: Se audita que ningún tipo de información sensible se almacena en los registros de la aplicación: cookies, información en métodos “GET”, credenciales de autenticación, etc.; la aplicación registra las acciones que se producen en la aplicación por parte de los usuarios y especialmente en casos de acciones potencialmente peligrosas; todos los eventos de autenticación, fallidos o no, se registran; etc.
• Criptografía: Incluye la revisión de que no se transmite ningún tipo de datos sensible sin cifrar, sea internamente o externamente y que los algoritmos o métodos de cifrado son reconocidos y poseen la robustez necesaria.
• Secure Code Environment: Sobre este punto se analiza la estructura de ficheros/directorios para asegurar que ningún recurso que no debería serlo podría ser accesible por el usuario; se realizan correctamente las reservas/liberaciones de memoria; las peticiones SQL dinámicas no son vulnerables a ataques de Inyección SQL; asegurar que todas las decisiones lógicas por defecto tienen una cláusula por defecto; etc.
• Gestión de Sesiones: En este apartado se verifica cómo y cuándo se crea la sesión para un usuario, autenticado y no autenticado; la complejidad del ID de sesión y su robustez; cómo se almacenan las sesiones: p.e. en una base de datos, en memoria, etc.; el tratamiento de la caducidad de las sesiones; cómo se gestiona la inactividad HTTP; cómo se gestionan las funciones de logout y su efecto en la gestión de sesiones; etc.

Resultados