Muchas empresas que actualmente trabajan en seguridad móvil se centran en estos aspectos:
Gestión de dispositivos móviles (dispositivos de aprovisionamiento / desaprovisionamiento)
Seguridad del dispositivo móvil (política de usuario y correlación de uso móvil)
Gestión de aplicaciones móviles (comportamiento de la aplicación y correlación de políticas de usuario)
Protección de datos (aplicación que intenta robar información confidencial / borrado remoto de datos)
La razón principal aquí es que no es tan fácil inspeccionar y aplicar políticas sobre cómo un teléfono móvil usa Internet en comparación con un navegador en una computadora de escritorio
- ¿Realmente todo está pasando a dispositivos móviles, no estoy seguro de iniciar mi inicio como una aplicación web o una aplicación móvil?
- ¿Por qué algunas aplicaciones web grandes no están diseñadas para responder (Facebook, LinkedIn, Pinterest, Quora, etc.)?
- ¿Qué software / sitio / aplicación es bueno para administrar los gastos diarios?
- ¿Cuál es la mejor aplicación para aprender a tocar la guitarra?
- Si pudieras crear una aplicación para ti que actualmente no está en el mercado, ¿cuál sería?
Miremos desde la perspectiva de la Autenticación y Autorización de “AAA” (Autenticación, Autorización, Auditoría)
En primer lugar, aquí hay un buen recurso que contrasta la seguridad móvil con la web.
https://www.owasp.org/index.php/…
Autenticación
Web
Para las aplicaciones web, las cookies se usan generalmente para mantener información de estado autenticada sobre el cliente. Las cookies pueden ser del siguiente tipo:
(a) Cookies HTTP : la visibilidad está dentro del mismo navegador
(b) Cookies Flash (LSO): las cookies almacenadas en Flash Player son visibles en diferentes navegadores
(c) Evercookie: un mecanismo para asegurarse de que todas sus acciones sean rastreables por usted.
La autenticación basada en cookies podría ser vulnerable a los ataques CSRF (Cross Site Request Forgery), XSS (Cross Site Scripting), MITM (Man-in-the-middle). Cada uno de ellos es un tema separado en sí mismo. Aquí hay un artículo de blog sobre ellos.
http://sitr.us/2011/08/26/cookie…
Autenticación basada en SAML, la identidad federada también ha existido por un tiempo.
Un tema relacionado con la autenticación es la huella digital del dispositivo.
Aquí hay un buen artículo sobre lo mismo:
https://www.cs.ucsb.edu/~vigna/p… La principal diferencia aquí es que esto incluye un montón de técnicas para que un tercero determine satisfactoriamente si usted es, quién cree que es.
Móvil
El tráfico de Internet móvil no es solo a través de HTTP y un navegador. Las aplicaciones se comunican con servidores de fondo. Por lo tanto, muchos supuestos que eran válidos para la autenticación / seguimiento basado en cookies no son válidos para las aplicaciones móviles.
Además, existen diferencias entre las plataformas (Android, iOS, Windows). Esto se hace más pronunciado si su dispositivo móvil necesita ser configurado para ser utilizado en una VPN corporativa (Red Privada Virtual) o un servidor proxy.
Aquí hay un par de artículos que muestran las diferencias en las aplicaciones / aplicaciones basadas en navegador,
http://www.iab.net/media/file/IA…
http: //www.mobileapptracking.com…
Las aplicaciones móviles de Android pueden tener ingeniería inversa, y cosas como los archivos creados, las API utilizadas pueden proporcionarle a un atacante la lógica cliente-servidor.
Autenticación de Windows Mobile : http://msdn.microsoft.com/en-us/…
Autenticación de iOS:
https://developer.apple.com/libr… – Hablan sobre Kerberos, autenticación LDAP, entre otros.
Autenticación de Android / oAuth:
https://developers.google.com/ac….
https://developers.google.com/ac…
Vector de ataque: alguien roba su teléfono inteligente, lo arraiga y obtiene información sobre las contraseñas almacenadas en una base de datos SQLite local, o descarga la memoria del sistema en un archivo y obtiene información sobre detalles confidenciales como el número de tarjeta de crédito de la memoria.
AUTORIZACIÓN
Web:
En realidad, SAML aplica un modelo de autorización bastante bueno. Un administrador podrá establecer reglas muy fácilmente para decir que las personas que pertenecen a un grupo en particular pueden acceder a un recurso en particular (URL de punto final de un documento / video, etc.). Por lo tanto, asegúrese de que solo las personas autorizadas tengan acceso.
Móvil:
(1) Parte del problema se reduce a la validación tanto del lado del cliente como del lado del servidor. Es posible realizar ingeniería inversa de la aplicación del lado del cliente y desencadenar una solicitud apropiada al servidor a través del emulador o la aplicación modificada. Específicamente:
(a) Asumiendo que una función particular en una aplicación móvil será visible solo para usuarios autorizados.
(b) Suponiendo que solo los usuarios autenticados podrán generar una solicitud de servicio para una aplicación móvil en su back-end
(2) La otra parte del problema es la fuente del rango de permisos que su aplicación le solicita, como usuario antes de la instalación. Por ejemplo, a través de descompilación, análisis de código estático, podríamos inferir que se realizan llamadas API. Además, si la aplicación se ejecuta en un entorno de sandbox, podríamos tener una idea de las llamadas dinámicas de red de comportamiento que la aplicación realmente está haciendo. (¿Subiendo sus contactos cada 2 horas?)
En este artículo, http://www.rsaconference.com/wri…, los autores dan un ejemplo de un juego de Android de ingeniería inversa, que almacenaba el número de “monedas de oro” en un archivo. Una vez que el usuario pudo editar y cambiar el contenido del archivo, el servidor no distinguió los cambios realizados. (Sin validación del lado del servidor).
En este artículo, los autores hablan sobre algunos vectores de ataque para aplicaciones móviles.
https://www.owasp.org/images/c/c…
