¿Qué pruebas se pueden realizar en las aplicaciones móviles para determinar si son seguras?

0

Mi compañía está buscando trabajar con un proveedor backend de un cliente potencial para poder crear una aplicación para ellos. Para hacer esto, necesitamos usar su API. Hemos hablado con esta empresa y están preocupados por la seguridad, por lo que hemos dicho que solo nos permitirán lanzar la aplicación si un tercero la prueba de penetración.

La aplicación permitirá a los usuarios iniciar sesión y acceder a su información financiera, por lo que tiene sentido que quieran asegurarse de que todo esté seguro, pero, a mi entender, las "pruebas de penetración" realmente no tienen sentido para una aplicación móvil. ¿Es esto correcto? ¿Qué podemos hacer para que la aplicación sea segura? ¿Hay un nombre para un tipo de prueba de seguridad de la aplicación estándar que podría ser realizada por un tercero?

    
pregunta D Roberts 16.09.2018 - 21:58
fuente

2 respuestas

4

Hablando como un antiguo consultor de seguridad que realizaba regularmente pruebas de penetración de aplicaciones móviles de terceros, tiene sentido. En la práctica, las aplicaciones para dispositivos móviles son un poco menos susceptibles al control de la caja negra que otros tipos de aplicaciones (como las aplicaciones web o los controladores en modo kernel), pero hay muchas cosas que puede hacer incluso la caja negra (y más con blanco). Aunque la aplicación de ingeniería inversa para la mayoría de las aplicaciones de Android es tan fácil, casi siempre son de caja blanca.

Se encontraron algunos problemas de seguridad comunes:

  • Las aplicaciones no realizan la validación de TLS correctamente (por ejemplo, permiten certificados autofirmados o incluso certificados no válidos arbitrarios).
  • Las aplicaciones que tenían puntos de entrada vulnerables (asociaciones de archivos, esquemas URI, contratos compartidos u otras formas de invocarlos mediante programación y luego hacer que hagan algo que no deberían).
  • Aplicaciones que utilizaron bibliotecas o SDK obsoletos con vulnerabilidades conocidas.
  • Aplicaciones que usaban vistas web con puentes JavaScript inseguros.
  • Las aplicaciones que usaban HTTP en lugar de HTTPS a veces.
  • Las aplicaciones que usaban vistas web pero no bloquearon sus rutas o ejecución de JS, y eran vulnerables a las vulnerabilidades de la aplicación web y / o al phishing.
  • Aplicaciones que almacenan secretos (credenciales, tokens, datos privados, etc.) en texto sin formato y / o en ubicaciones legibles.
  • Las aplicaciones que almacenaron claves u otros secretos (por ejemplo, una clave de API para un servicio web) en sus archivos binarios, como si un atacante no pudiera aplicar ingeniería inversa a la aplicación para encontrarla.
  • Las aplicaciones que usaban el código nativo de forma insegura y tenían errores de corrupción de memoria.
  • Aplicaciones que utilizaron la criptografía de forma incorrecta y, por lo tanto, insegura.

Hay muchos más que pueden surgir, aunque esos son algunos de los más comunes y / o severos. Las aplicaciones móviles son definitivamente capaces de tener errores de seguridad y deben someterse a revisiones de seguridad, incluidas las pruebas de penetración.

    
respondido por el CBHacking 17.09.2018 - 00:32
fuente
0

Además de las pruebas de penetración mencionadas anteriormente, puede hacer que un tercero realice una revisión segura del código o que ambas sean realizadas por la misma organización. Si tiene alguna herramienta de análisis estático, puede proporcionar los resultados, así como una lista de vulnerabilidades que la herramienta verifica.

En mi función rutinariamente desarmo las aplicaciones y encuentro un código que se puede aprovechar en determinadas circunstancias debido a decisiones de diseño.

    
respondido por el McMatty 17.09.2018 - 04:34
fuente

Lea otras preguntas en las etiquetas