Prueba de penetración de app móvil antes de pagar — ¿hay alguna lista de control de seguridad q podamos aplicar nosotros mismos?

Haced q vuestro equipo haga mañana mismo estos tres controles: 1) Desactivad los logs de la app, q en las salidas de consola nunca se imprima información de cliente o de token. 2) Asegurad q los datos sensibles copiados al portapapeles del dispositivo se borren automáticamente. 3) Probad cómo se comporta la app en dispositivos con acceso root.

Podéis incluir herramientas de análisis estático de código abierto en vuestro proceso de compilación. Hay herramientas gratuitas q escanean vuestro código automáticamente y listan en unos minutos las claves ocultas y las funciones de almacenamiento inseguras. Yo diría q no paguéis a nadie de fuera por pruebas sin haberlas ejecutado antes.

El año pasado cometimos el mismo error. Pagamos 4.200 libras por la prueba y de los 12 hallazgos del informe, 9 eran claves de prueba olvidadas en el código y archivos de caché local guardados sin cifrar. Si hubiéramos mirado antes, los auditores podrían haberse centrado en el flujo de pago q de verdad tenían q hurgar.

Vuestra propia lista de control es muy buena idea pero nunca la veáis como alternativa a la prueba de penetración oficial. La ceguera del equipo es inevitable cuando buscas los fallos del código q tú mismo escribiste. Estos controles deben hacerse no para cancelar la prueba sino para q el dinero gastado valga la pena.

nosotros usamos una infraestructura híbrida o sea q la app en realidad corre dentro de una vista web. bueno ¿Los controles de almacenamiento local y certificados q mencionáis también aplican igual en apps híbridas?

mucho cuidado con el tema de las claves api secretas olvidadas en el repo de código... nuestro equipo había subido a producción la clave temporal q escribió para el entorno de pruebas, lo notamos en el último momento. estas cosas se pillan hasta con una simple búsqueda en el repositorio.

Hace dos años, en la primera versión de nuestra app de entregas un cliente consiguió meterse por medio con una simple herramienta proxy y poner el importe de su propio pedido a 0 libras. Xq calculábamos el precio en la app móvil y lo enviábamos así al servidor. Desde ese día tratamos al cliente móvil con cero confianza.

Vais por muy buen camino. Las empresas de seguridad ofrecen soluciones estándar para cada hallazgo de la prueba pero corregir vuestro código os toca a vosotros igual. Si agotáis vuestra propia lista y vais a la empresa con una estructura limpia, el tiempo de prueba pasa mucho más eficiente y el informe q recibís se convierte en un documento de prestigio en las ventas corporativas.

no sabía eso.

A nosotros nos pasó esto. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Creo que es difícil hablar con tanta claridad sobre lista de control de seguridad de apps móviles. El tiempo que tardas en detectar un problema determina directamente su coste.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Aquí hay una trampa, no puedo dejar de mencionarla. Las decisiones apresuradas son las que hay que corregir seis meses después.

Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Le agradecería que compartiera el resultado.

Gracias por escribir.

El punto que más se pasa por alto sobre lista de control de seguridad de apps móviles es este: Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

También me gustaría saber si alguien lo hace de otra manera.

Separemos los conceptos, se están confundiendo. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

También me gustaría saber si alguien lo hace de otra manera.

Tema muy oportuno. No confíes en una sola medida; ve capa por capa.

Tiene razón.