Criterios específicos para pruebas de vulnerabilidades de aplicaciones móviles

De Gobmx
Saltar a: navegación, buscar

Objetivo

El objetivo del presente documento es listar los criterios utilizados para la evaluación del producto “reporte de resultado de revisión de vulnerabilidades para Apps móviles ”, entregado por las dependencias a la Secretaría de la Función Pública, así como los criterios considerados para iniciar la evaluación. Se describen además los niveles de severidad que han de otorgárseles a los hallazgos detectados durante la evaluación del producto y las distintas conclusiones que pueden resultar de la evaluación de acuerdo a los criterios y severidades.

Severidad de criterios y hallazgos

La severidad se refiere al grado de impacto en la seguridad de la app que tiene la no satisfacción de un criterio de evaluación y los hallazgos identificados a partir de ese criterio de evaluación.

Los niveles de severidad que serán utilizados durante las evaluaciones para clasificar tanto a criterios como a hallazgos son los siguientes:

Grado Severidad Descripción Recomendación
Crítica Se refiere a aspectos imprescindibles que comprometan la seguridad
confidencialidad de los datos de la app y que sean un factor clave
para elevar el grado de riesgo. Por ejemplo, hallazgos con severidad
crítica detectados en el análisis de vulnerabilidades y que no se
encuentran cerrados, no se realizan los análisis incluyendo el Top 10
de vulnerabilidades la OWASP, no se cuenta con conexión segura,
entre otros.También se consideran críticos, aquellos aspectos que
sean necesarios para identificar la aplicación considerada en el
análisis. Por ejemplo nombre de la aplicación y fecha en que se realizó
el análisis.
Es necesario realizar la corrección de los hallazgos y lograr
el cumplimiento de los criterios de evaluación de severidad
crítica antes de publicar la app en la plataforma gob.mx
Alta Se refiere a aspectos informativos de la app que pueden afectar
directamente a la seguridad de la misma o que puedan servir para
identificar más claramente la naturaleza de los hallazgos.
Por ejemplo, descripción del ambiente donde se realizaron los
análisis de vulnerabilidades, omisiones de las descripciones de los
hallazgos detectados así como su posible impacto en el sistema, etc.
Se recomienda realizar las adecuaciones pertinentes para
atender los hallazgos, de primera instancia no se identifica
un riesgo mayor en la publicación de la app en la plataforma
gob.mx
Media Se refiere a aspectos informativos de los reportes de vulnerabilidades
que no afecten de manera directa a la seguridad de la app, pero que
son importantes para registrar de manera completa la calidad desde
la perspectiva de seguridad.
Se recomienda realizar las adecuaciones pertinentes para
atender los hallazgos, de primera instancia no se
identifica un riesgo mayor en la
publicación de la app en la plataforma gob.mx



Criterio para iniciar evaluación

Para iniciar la evaluación completa de los productos de tipo “reporte de resultado de revisión de vulnerabilidades para Apps móviles” entregado por las dependencias a La Secretaría de la Función Pública, es necesario que estos cuenten con la información mínima suficiente para evidenciar que el aplicativo del cual se describen los resultados de análisis de vulnerabilidades cubre el estándar de servicios digitales de gob.mx.

En caso de que no se encuentre dicha información en los productos entregados por las dependencias a La Secretaría de la Función Pública, no es posible realizar el análisis de manera completa y confiable.

La información necesaria es aquella que muestre los resultados del análisis para los aspectos críticos y determinantes referentes a los temas descritos a continuación:

Almacenamiento inseguro de datos

Se refiere al manejo inseguro de los datos almacenados dentro de la aplicación móvil incluyendo base de datos locales, archivos de log, cookies, almacenamiento en memoria SD, archivos XML, sincronización con la nube. Además a las filtraciones de dicha información.

Comunicación insegura

Este riesgo cubre todos los aspectos involucrados en transmisión de información de forma insegura. Incluye comunicaciones de móvil a móvil, comunicaciones de aplicación a servidor o comunicaciones de móvil a otro. Este riesgo incluye todas las tecnologías de comunicación que un dispositivo móvil podría utilizar, incluyendo problemas de comunicación en TLS, problemas de NFC, Bluetooth y WiFi. También cubre el uso incorrecto de criptografía o uso de protocolos antiguos o vulnerables.

Autenticación y autorización inseguras

Se refiere al manejo inseguro de la autenticación del usuario, o la falta de autenticación cuando debería realizarse, mal manejo de sesiones, o a no mantener la identidad del usuario cuando es requerido. Adicionalmente, también se refiere al manejo de las autorizaciones que se brindan al usuario por medio de la autenticación. Es importante reconocer la diferencia entre autenticación y autorización. La autenticación es el acto de identificar a un individuo. Autorización es el acto de comprobar que el individuo identificado tiene los permisos necesarios para realizar el acto. Los dos están estrechamente relacionados como verificaciones de autorización siempre debe seguir inmediatamente la autenticación de una solicitud entrante de un dispositivo móvil.

Baja calidad del código

Se refiere a riesgos o problemas de seguridad en implementación a nivel de código en el cliente móvil. Son los riesgos que provienen de vulnerabilidades como desbordamientos de búfer, vulnerabilidades de cadena de formato y varios otros errores de nivel de código donde la solución es reescribir algún código que se esté ejecutando en el dispositivo móvil.

Los criterios considerados para evaluar cada uno de los temas descritos, se encuentran listados y marcados como críticos en la sección “Criterios de evaluación” de este documento.

Criterios de evaluación

Para evaluar la completitud y calidad de los productos, se realizará verificación estática basada en una lista de verificación que contiene los criterios de evaluación tanto generales como técnicos.

Criterios generales de evaluación

Se refiere a aquellos puntos que han de ser evaluados en el producto pero que no buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, sino realizar un reconocimiento del producto, contemplan aspectos de identificación de aplicaciones, dependencias, herramientas utilizadas y secciones del reporte motivo de la evaluación.

Los criterios generales de evaluación del producto, así como su severidad, se listan a continuación:

ID Descripción Nivel de interacción
1 Se identifica el nombre de la Aplicación. Crítica
2 Se identifica la dependencia de gobierno a la que pertenece el sistema Media
3 Se contemplan análisis dinámico y estático de vulnerabilidades Crítica
4 Se incluye en el reporte al menos un ciclo previo y el ciclo de revisión posterior a la corrección de los
hallazgos
Crítica
5 Se resume el resultado de las revisiones realizadas Alta
6 Se identifican las fechas en que fue realizado el análisis de vulnerabilidades Crítica
7 Se describe el objetivo de la revisión / ciclo Media
8 Se identifica el tipo y versión de los sistemas operativos que soporta la aplicación móvil. Alta
9 Se describe la variedad de los diferentes dispositivos móviles que tiene como alcance la aplicación. Media
10 Se describe la tecnología y framework con la que fue creada la solución móvil. Incluyen información de la
aplicación y de los servicios web.
Media


Criterios técnicos de evaluación

Se refiere a aquellos puntos que han de ser evaluados en el producto que buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, a fin de identificar si la app que ha sido analizada en busca de vulnerabilidades cumple con los requerimientos necesarios para su publicación en el portal gob.mx

Los criterios técnicos de evaluación del producto, así como su severidad, se listan a continuación:

ID Descripción Nivel de interacción
8 Todos los hallazgos contenidos en los reportes de análisis de vulnerabilidades con severidad Crítica se encuentran corregidos o
existe justificación para su no corrección.
Crítica
9 En el listado de reglas de seguridad para el análisis dinámico, se considera la validación de las vulnerabilidades más críticas
que afectan a una aplicación Móvil definido en el TOP 10 de la OWASP:
  • Uso incorrecto de la plataforma
  • Almacenamiento de datos inseguro
  • Comunicación Insegura
  • Autenticación insegura
  • Criptografía insuficiente
  • Autorización no segura
  • Calidad del código del cliente
  • Manipulación de código (deseable)
  • Ingeniería inversa (deseable)
  • Funcionalidad Extraña
Crítica
10 Se identifican los resultados de las técnicas de inyección de código SQL y no se presenta riesgo de inyección.
Todos los campos de entrada de la app y los servicios web se encuentran validados a caracteres especiales. Las evidencias
mostradas hacen referencia a la aplicación móvil y también a los servicios API.
Crítica
11 Se muestra evidencia que la aplicación móvil a la que se le hicieron los análisis no sea una versión de prueba y tiene
un certificado válido.
Crítica
12 Se valida que la aplicación móvil tras varios intentos fallidos con datos incorrectos en el login, este se bloquea temporalmente,
evitando ataques por medio de fuerza bruta.
Alta
13 Se muestra evidencia que la aplicación no permite copiar y pegar en campos que contengan o manejen información sensible.
Por ejemplo: Datos de usuarios contraseñas, cuentas bancarias etc.
Alta
14 Se especifica o se aprecia que la aplicación no almacena información sensible del usuario como nombre deusuario y
contraseñas en los registros de la aplicación o que la información almacenada localmente en el dispositivo esta
protegida.
Crítica
15 Se informa el tipo de encriptación que tienen los datos sensibles al ser guardados en localmente en el dispositivos. La
encriptación utilizada no es una encriptación débil, como: MD5 o SHA1
Alta
16 Se especifica si al salir de la aplicación o al cerrarla no se quede activa la sesión del usuario. Alta
17 Se valida que para la comunicación se utiliza en la aplicación el protocolo TLS actual disponible. Alta
18 Se describen los resultados del análisis de comunicaciones entre la aplicación móvil y el backend. La
información enviada viene protegida.
19 Se evidencia que al momento en que se está instalando la aplicación, esta debe mostrar que permisos requiere por parte del
usuario para acceder a mas funcionalidades del dispositivo como: cámara, GPS, almacenamiento int.
y ext, etc.
Media
20 Los datos sensibles como contraseñas se ocultan con otros símbolos cuando se escriben de modo que no son visibles Media
21 Se identifica la versión del código evaluado. Alta
22 En el listado de reglas de seguridad estática se encuentran clasificadas por:
  • Tecnología para la cual aplica
  • Severidad o Criticidad
Alta
23 Se identifica la cantidad de líneas de código evaluadas. Alta
24 La cantidad de líneas de código están catalogadas por tecnología. Alta
25 Se describen las tecnologías con que fue desarrollada la aplicación. Alta
26 Se describen cantidad de archivos evaluados durante el análisis de vulnerabilidades estáticas Alta
27 Se tienen todos los componentes de la aplicación identificados, tanto de terceros (frameworks, librerías), como propios, y se
tienen identificadas las vulnerabilidades conocidas para estos componentes.
Alta