La perspectiva de un desarrollador sobre las reglas de seguridad de las aplicaciones móviles

Este artículo es el segundo de una serie que ilustra la perspectiva del desarrollador sobre la seguridad de las aplicaciones móviles del colaborador invitado y desarrollador Evan Rose, socio gerente de Rose Digital. La primera publicación cubría la planificación de la seguridad de las API móviles y, en esta entrega, Evan explica lo que los desarrolladores deben tener en cuenta al codificar sus aplicaciones móviles.

Preocupaciones durante la codificación

Mientras escriben aplicaciones móviles, muchos desarrolladores pasan por alto las mejores prácticas de seguridad para acelerar el tiempo de comercialización. Tanto es así, de hecho, que casi el 25 por ciento de las aplicaciones móviles contienen al menos una falla de seguridad importante. Esa es una gran cantidad de aplicaciones con fallas críticas. Para las organizaciones, tener una brecha de seguridad móvil puede disuadir a los usuarios de usar su aplicación y dañar seriamente sus tasas de adopción. Afortunadamente, hay algunas reglas a seguir durante el desarrollo que lo ayudarán a cubrir sus bases.

Almacenamiento de tokens en el dispositivo

El almacenamiento seguro de tokens OAUTH dentro de su aplicación puede ser un factor decisivo en la seguridad de su aplicación. Almacenar el token en cualquier lugar al que pueda acceder una entidad malintencionada puede poner en riesgo no solo su aplicación, sino también la seguridad de su API. Si bien el almacenamiento de datos confidenciales en el almacenamiento del dispositivo siempre es un riesgo, puede mitigarlo en los dispositivos móviles almacenando sus datos en dos ubicaciones:

Cifrado

Un tipo particularmente dañino de brecha de seguridad es la exposición y publicación de datos confidenciales del usuario. ¿Dónde está almacenando datos en su aplicación? ¿Está seguro de que almacenar los datos es absolutamente necesario? Como desarrollador, es importante operar con la suposición de que no hay almacenamiento seguro en un dispositivo móvil porque los sistemas operativos siempre tendrán errores que permitan que el malware rootee o haga jailbreak al dispositivo y lea los datos escritos por su aplicación. Antes de tomar la decisión de almacenar sus datos en el dispositivo, evalúe sus preocupaciones de seguridad y usabilidad. Si decide almacenar sus datos en el dispositivo, debe considerar qué método de cifrado utilizará para proteger esos datos de miradas indiscretas. Cualquier información de identificación personal (PII) almacenada en el almacenamiento local debe cifrarse. Use las bibliotecas de cifrado de iOS y Android para esto. ¡Lo más importante es que siempre cifre cualquier comunicación desde su aplicación!

Mantener al cliente tonto

El código de la capa de presentación no es el lugar para mantener la lógica de la organización o el «cerebro» de su aplicación. Suponga que cualquier lógica que incluya en el cliente se puede ver o comprometer. Para las aplicaciones web, esto es tan simple como abrir Chrome DevTools y descifrar su código. Para las aplicaciones móviles nativas, existen muchas herramientas de ingeniería inversa para ayudar a un atacante a comprender cómo funciona su aplicación en detalle, exponiendo su propiedad intelectual y destacando los posibles vectores de ataque. Cuando, y si, un individuo malicioso aplica ingeniería inversa a su aplicación, ¡no querrá que encuentre el algoritmo patentado que impulsa toda la experiencia!

Mire sus bibliotecas de terceros

La mayoría de los ingenieros conocen el mantra «no te repitas» (DRY). El principio a menudo se extiende a no reinventar la rueda recreando bibliotecas de uso común por sí mismo. Si bien esto es en gran medida algo bueno porque ha llevado a una proliferación de paquetes en lenguajes de programación populares, también fomenta la confianza en el código de otras personas. Se pueden usar los paquetes de otras personas, solo trate de asegurarse de que está investigando a las personas y empresas cuyo código está poniendo en su aplicación. Si no puede ver el código antes del empaque, está tratando con el equivalente a un dulce de un extraño. Sería prudente no tomarlo.

Qué hacer antes del parto

Antes de enviar su aplicación a producción, debe evaluar la postura de seguridad de back-end de su aplicación con algunas pruebas rápidas de cordura:

  • Fuzz y pruebas de entrada no válida — Probar entradas aleatorias y entradas explícitamente inválidas para asegurarse de que sus validadores no se dejen engañar.
  • Entrada maliciosa — Esta prueba cubre un amplio conjunto de ataques maliciosos que incluyen secuencias de comandos entre sitios, inyección de SQL, manipulación de verbos HTTP, inyección de LDAP, inyección de ORM, inyección de XML, inyección de SSI, inyección de código, inyección de comandos del sistema operativo y desbordamiento de búfer.
  • Falsificación de solicitud entre sitios — Este ataque hace que los usuarios realicen acciones de cambio de estado dentro de su aplicación sin saber que lo están haciendo. Este tipo de ataque es un poco más difícil con las aplicaciones móviles, pero si su aplicación está descifrada, entonces es posible.
  • Debilidad en la configuración de SSL/TLS — Para usar TLS con éxito, debe asegurarse de que sus protocolos, cifrados, claves y renegociación estén configurados correctamente. También debe asegurarse de la validez del certificado.

Para obtener más información sobre las pruebas de seguridad, puede consultar OWASP, que proporciona excelentes recursos para obtener más información sobre cómo puede proteger y probar su aplicación. Además, eche un vistazo a la colección NowSecure de más de 50 mejores prácticas de desarrollo móvil seguro.

Si su organización no tiene un equipo de seguridad, es difícil sacar a los ingenieros de sus tareas asignadas para realizar revisiones periódicas. El uso de herramientas de prueba de seguridad de aplicaciones móviles lo ayuda a comprender cómo su aplicación se enfrenta a las vulnerabilidades más recientes.

¡Buena suerte y feliz codificación!

Deja un comentario