Documento de Owasp

HERRAMIENTA OWASP MOBILE
6-6-2018
OWASP Mobile Security Project

El mundo de la seguridad es un tema que lleva con nosotros desde casi el inicio de la informática
y cada vez cobra más importancia en el mundo empresarial. Las empresas gastan millones de
euros anuales en todo tipo de seguridad informática para proteger sus activos y evitar que entren
en sus sistemas para apropiarse o alterar sus contenidos.
¿Qué es OWASP?
En el año 2001 se creó la fundación OWASP (Open Web Application Security Project), cuyo
objetivo es descubrir y evitar las causas por las que un software es inseguro. Es una organización
sin ánimo de lucro formada por empresas y organizaciones de todo el mundo. Su tarea es la de
trabajar juntos para crear documentos, artículos y herramientas de uso público para combatir las
vulnerabilidades en el mundo del software.
Al ser una empresa sin ánimo de lucro, su financiación depende básicamente de aportaciones de
la Comunidad y sus donaciones. Actualmente es el referente en el mundo de la seguridad web a
hora de tomar decisiones para hacer las aplicaciones web más seguras.
OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados
sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles,
tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.
Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo
de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).
Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas
para evaluar la seguridad de las aplicaciones móviles.
6-6-2018
OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden
aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima
seguridad posible. Para ello OWASP nos propone su Mobile Security Project.
Recursos OWASP Mobile Security Project
A continuación nombraremos algunos de los recursos disponibles en este proyecto.
 Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en
aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.
 Developer Cheat Sheet: Consejos para el desarrollador para evitar errores que puedan dar
lugar a vulnerabilidades en su aplicación.
 App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información
interesante para llevar a cabo la evaluación de la seguridad de la aplicación.
 Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el
ciclo de desarrollo de software seguro (S-SDLC).
 Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también
podemos encontrar una guía de test para ayudar al auditor durante sus tareas de
evaluación de los controles de seguridad de la aplicación.
 Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el
desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles
para las diferentes plataformas (Android, iOS o Windows Phone).
 Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el
top 10 de los controles de seguridad a evaluar.
Los 10 principales riesgos móviles - Lista final 2016
o M1 - Uso inadecuado de la plataforma. Esta categoría cubre el uso indebido de una

característica de la plataforma o la imposibilidad de utilizar los controles de seguridad de la
plataforma. Puede incluir intenciones de Android, permisos de plataforma, mal uso de TouchID,
el llavero o algún otro control de seguridad que sea parte del sistema operativo móvil. Hay
varias formas en que las aplicaciones móviles pueden experimentar este riesgo.
6-6-2018
Agentes de Vectores de Impactos Impactos

Debilidad de seguridad
amenaza ataque técnicos comerciales
Aplicación /
Aplicación Explotabilidad Prevalencia Detectabilidad Impacto
específico del
específica FÁCIL COMÚN PROMEDIO SEVERO
negocio
Esta categoría Los vectores de Para explotar esta El impacto El impacto

cubre el uso ataque vulnerabilidad, la organización técnico de esta comercial de esta
indebido de corresponden a debe exponer un servicio web vulnerabilidad vulnerabilidad
una los mismos o una llamada API que corresponde al corresponde al
característica vectores de consume la aplicación impacto técnico impacto
de la ataque móvil. El servicio expuesto o de la comercial de la
plataforma o la disponibles a llamada API se implementa vulnerabilidad vulnerabilidad
imposibilidad través del utilizando técnicas de asociada asociada
de utilizar los tradicional codificación inseguras que (definida en el (definida en el
controles de OWASP Top producen una vulnerabilidad TOP 10 de Top 10 de
seguridad de la Ten. Cualquier OWASP Top Ten dentro del OWASP) que el OWASP) que el
plataforma. llamada API servidor. A través de la interfaz adversario está adversario está
Puede incluir expuesta puede móvil, un adversario puede explotando a explotando a
intenciones de servir como alimentar entradas vulnerables través del través del
Android, vector de o secuencias de eventos dispositivo dispositivo móvil.
permisos de ataque aquí. inesperados al punto móvil.
Por ejemplo, un
plataforma, mal vulnerable. Por lo tanto, el
Por ejemplo, unadversario puede
uso de adversario se da cuenta de la explotar una
adversario
TouchID, el vulnerabilidad original OWASP puede explotar vulnerabilidad de
llavero o algún Top Ten en el servidor. una secuencias de
otro control de vulnerabilidad comandos entre
seguridad que de secuencias sitios (XSS) a
sea parte del de comandos través del
sistema entre sitios dispositivo
operativo móvil. (XSS) a través móvil. Esto
del dispositivo corresponde a
móvil. Esto los impactos de
corresponde a negocios de la
la categoría Categoría 10 A3
OWASP Top - XSS de
Ten A3 - XSS OWASP.
con un impacto
técnico
moderado.
6-6-2018
¿Soy vulnerable al 'uso inadecuado de la plataforma'?
La característica definitoria de los riesgos en esta categoría es que la plataforma (iOS, Android,
Windows Phone, etc.) proporciona una característica o una capacidad que está documentada y
bien entendida. La aplicación no puede usar esa capacidad o la usa incorrectamente. Esto difiere
de otros 10 principales riesgos móviles porque el diseño y la implementación no son estrictamente
el problema del desarrollador de la aplicación.
Hay varias formas en que las aplicaciones móviles pueden experimentar este riesgo.
1. Violación de las pautas publicadas. Todas las plataformas tienen pautas de desarrollo
para la seguridad (cf, ((Android)), ((iOS)), ((Windows Phone))). Si una aplicación contradice
las mejores prácticas recomendadas por el fabricante, estará expuesta a este riesgo. Por
ejemplo, hay pautas sobre cómo usar iOS Keychain o cómo proteger los servicios
exportados en Android. Las aplicaciones que no sigan estas pautas experimentarán este
riesgo.
2. Violación de la convención o práctica común. No todas las mejores prácticas están
codificadas en la guía del fabricante. En algunos casos, existen las mejores prácticas de
facto que son comunes en las aplicaciones móviles.
3. Uso indebido involuntario. Algunas aplicaciones tienen la intención de hacer lo correcto,
pero en realidad obtienen una parte de la implementación incorrecta. Esto podría ser un
error simple, como configurar el indicador incorrecto en una llamada API, o podría ser un
malentendido sobre cómo funcionan las protecciones.
Las fallas en los modelos de permiso de la plataforma caen en esta categoría. Por ejemplo, si la
aplicación solicita demasiados permisos o los permisos incorrectos, es mejor categorizarlos aquí.
¿Como evito el uso inadecuado de la plataforma?
Las prácticas seguras de codificación y configuración se deben utilizar en el lado del servidor de la
aplicación móvil. Para obtener información específica sobre vulnerabilidades, consulte los
proyectos OWASP Web Top Ten o Cloud Top Ten.
M2 - Almacenamiento de datos inseguros. Esta nueva categoría es una combinación de M2 +

M4 de Mobile Top Ten 2014. Esto abarca el almacenamiento de datos inseguros y la fuga de
datos involuntarios.

Aplicación /
Aplicación Explotabilidad Prevalencia Detectabilida Impacto
específico
específica FÁCIL COMÚN d PROMEDIO SEVERO
del negocio
Los agentes de En el caso de Las vulnerabilidades de Esto puede Las
amenazas incluyen que un almacenamiento de datos provocar la vulnerabilidad
lo siguiente: un adversario inseguras ocurren cuando pérdida de es de
adversario que ha alcance los equipos de desarrollo datos, en el almacenamie
6-6-2018
obtenido un físicamente el suponen que los usuarios mejor de los nto de datos
dispositivo móvil dispositivo móvil, o el malware no tendrán casos para un inseguros
perdido / el adversario acceso al sistema de usuario y, en el generalmente
robado; malware u conecta el archivos de un dispositivo peor de los conducen a
otra aplicación dispositivo móvil móvil y a la información casos, para los siguientes
reempaquetada a una sensible subsiguiente en muchos riesgos
que actúe en computadora con las tiendas de datos en el usuarios. Tamb comerciales
nombre del software dispositivo. Los sistemas ién puede para la
adversario y se disponible de archivos son de fácil provocar los organización
ejecute en el libremente. Estas acceso. Las siguientes propietaria de
dispositivo móvil. herramientas le organizaciones deben impactos la aplicación
permiten al esperar que un usuario o técnicos: de riesgo:
adversario ver malware malicioso extracción de
todos los inspeccione los almacenes la información  El robo de
directorios de de datos sensible de la identidad
aplicaciones de confidenciales. Se debe aplicación a  Fraude
terceros que a evitar el uso de bibliotecas través de  Daño de
menudo de cifrado malware móvil, reputación
contienen deficientes. Rootear o aplicaciones  Violación
información jailbreaking un dispositivo modificadas o de política
personal móvil evita cualquier herramientas externa
identificable (PII) protección de forenses. (PCI); o
almacenada u cifrado. Cuando los datos
La naturaleza  Pérdida
otros activos de no están protegidos de m
del impacto del
información adecuadamente, las negocio
confidencial. Un herramientas depende en
adversario puede especializadas son todo lo gran medida
construir que se necesita para ver de la
malware o los datos de la aplicación. naturaleza de
modificar una la información
aplicación robada. Los
legítima para datos
robar dichos inseguros
activos de pueden
información. generar los
siguientes
impactos
comerciales:
 El robo de
identidad;
 Violación
de la
privacidad;
 Fraude;
6-6-2018
 Daño a la
reputación;
 Violación
de política
externa
(PCI); o
 Pérdida de
material
¿Soy vulnerable al "almacenamiento de datos inseguros"?

Esta categoría de almacenamiento de datos inseguros y la fuga de datos no deseados. Los datos
almacenados de forma no segura incluyen, entre otros, los siguientes:
 Bases de datos SQL;

 Archivos de registro;
 Los datos XML almacenan los archivos manifiestos;
 Almacenes de datos binarios;
 Tiendas de galletas;
 Tarjeta SD;
 Nube sincronizada.
La pérdida de datos involuntarios incluye, entre otros, vulnerabilidades de:
 El sistema operativo;
 Marcos;
 Entorno del compilador;
 Nuevo hardware
 Dispositivos rooteados o Jailbreak
Esto es obviamente sin el conocimiento de un desarrollador. En el desarrollo móvil
específicamente, esto se ve más en procesos internos no documentados o poco documentados,
como:
 La forma en que el sistema operativo almacena datos, imágenes, pulsaciones de teclas,

registros y almacenamientos intermedios en caché;
 La forma en que el marco de desarrollo almacena datos, imágenes, pulsaciones de teclas,
registros y búferes;
 La forma o cantidad de marcos de anuncios, analíticos, sociales o de habilitación de datos
almacenan en caché datos, imágenes, pulsaciones de teclas, registros y búferes.
¿Cómo evito el "almacenamiento de datos inseguros"?
Es importante amenazar con modelar su aplicación móvil, sistema operativo, plataformas y marcos
para comprender los activos de información que la aplicación procesa y cómo las API manejan
esos activos. Es crucial ver cómo manejan los siguientes tipos de características:
 Caché de URL (tanto solicitud como respuesta);

 Almacenamiento en caché de teclado;
6-6-2018
 Copiar / Pegar el almacenamiento en memoria intermedia del búfer

 Antecedentes de aplicaciones;
 Datos intermedios
 Explotación florestal;
 Almacenamiento de datos HTML5;
 Objetos de cookie del navegador;
 Datos analíticos enviados a terceros
Un ejemplo visual
iGoat es una aplicación móvil deliberadamente vulnerable para que la comunidad de seguridad
explore este tipo de vulnerabilidades de primera mano. En el siguiente ejercicio, ingresamos
nuestras credenciales e ingresamos a la aplicación bancaria falsa. Luego, navegamos hacia el
sistema de archivos. Dentro del directorio de aplicaciones, podemos ver una base de datos
llamada "credentials.sqlite". Explorar esta base de datos revela que la aplicación está
almacenando nuestro nombre de usuario y credenciales (Jason: pleasedontstoremebro!) En texto
sin formato.
o M3 - Comunicación insegura. Esto incluye mala comunicación, versiones incorrectas de SSL,

negociación débil, comunicación clara de activos confidenciales, etc.

Aplicación /
específico del
negocio
Cuando se El factor de Las aplicaciones móviles a Este defecto Como mínimo, la
diseña una vulnerabilidad menudo no protegen el tráfico de expone los interceptación de
aplicación de monitorear la red. Pueden usar SSL / TLS datos de un datos
6-6-2018
móvil, los una red para durante la autenticación pero no usuario confidenciales a
datos se rangos de en otro lugar. Esta incoherencia individual y través de un
intercambia comunicacion conduce al riesgo de exponer los puede canal de
n es datos y las identificaciones de conducir al comunicación
habitualmen inseguras. Mo sesión a la interceptación. El uso robo de la dará lugar a una
te de forma nitorear el de la seguridad del transporte no cuenta. Si el violación de la
cliente- tráfico a significa que la aplicación lo haya adversario privacidad.
servidor. Cu través de la implementado intercepta una La violación de la
ando la red de un correctamente. Para detectar cuenta de confidencialidad
solución operador es fallas básicas, observe el tráfico administrador, del usuario puede
transmite más difícil que de red del teléfono. Los defectos todo el sitio
resultar en:
sus datos, monitorear el más sutiles requieren podría estar
debe tráfico de una inspeccionar el diseño de la expuesto. La
 El robo de
atravesar la cafetería aplicación y la configuración de mala
identidad;
red de local. En las aplicaciones. configuración
 Fraude, o
operadores general, los de SSL
 Daño r
del ataques también
dispositivo dirigidos son puede facilitar
móvil e más fáciles de ataques de
Internet.Los realizar. phishing y
agentes de MITM.
amenazas
podrían
explotar
vulnerabilid
ades para
interceptar
datos
confidencial
es mientras
viaja a
través del
cable. Los
siguientes
agentes de
amenaza
existen:
 Un
adversar
io que
compart
e su red
local
(Wi-Fi
compro
metido o
6-6-2018
monitore
ado);
 Dispositi
vos de
portador
a o de
red
(enrutad
ores,
torres de
telefonía
móvil,
proxy,
etc.); o
 Malware
en su
dispositi
vo móvil.
¿Soy vulnerable a la "comunicación insegura"?
Este riesgo cubre todos los aspectos de obtener datos del punto A al punto B, pero hacerlo
inseguramente. Incluye comunicaciones entre dispositivos móviles, comunicaciones de aplicación
a servidor o comunicaciones entre dispositivos móviles. Este riesgo incluye todas las tecnologías
de comunicación que un dispositivo móvil podría usar: TCP / IP, WiFi, Bluetooth / Bluetooth-LE,
NFC, audio, infrarrojos, GSM, 3G, SMS, etc.
Todos los problemas de comunicaciones TLS van aquí. Todos los problemas de NFC, Bluetooth y
WiFi van aquí.
Las características destacadas incluyen empaquetar algún tipo de datos confidenciales y
transmitirlo dentro o fuera del dispositivo. Algunos ejemplos de datos confidenciales incluyen
claves de cifrado, contraseñas, información privada del usuario, detalles de la cuenta, tokens de
sesión, documentos, metadatos y binarios. Los datos confidenciales pueden llegar al dispositivo
desde un servidor, pueden ir de una aplicación a un servidor o pueden ir entre el dispositivo y otra
cosa local (por ejemplo, un terminal NFC o una tarjeta NFC). La característica definitoria de este
riesgo es la existencia de dos dispositivos y algunos datos que pasan entre ellos.
Si los datos se almacenan localmente en el dispositivo, eso es #Insecure Data. Si los detalles de
la sesión se comunican de forma segura (por ejemplo, a través de una fuerte conexión TLS) pero
el identificador de sesión mismo es malo (tal vez es predecible, baja entropía, etc.), entonces se
trata de un problema de Autenticación no segura, no de comunicación.
Los riesgos habituales de la comunicación insegura son la integridad de los datos, la
confidencialidad de los datos y la integridad del origen. Si los datos pueden cambiarse durante el
tránsito, sin que el cambio sea detectable (por ejemplo, a través de un ataque de hombre en el
medio), ese es un buen ejemplo de este riesgo. Si los datos confidenciales pueden ser expuestos,
aprendidos o derivados observando las comunicaciones tal como suceden (es decir, escuchando)
o grabando la conversación como sucede y atacándola más tarde (ataque fuera de línea), ese
también es un problema de comunicación inseguro. Fallar en configurar y validar correctamente
6-6-2018
una conexión TLS (por ejemplo, comprobación de certificados, cifras débiles, otros problemas de
configuración de TLS) está aquí en una comunicación insegura.
¿Cómo evito la "comunicación insegura"?

Mejores prácticas generales
 Suponga que la capa de red no es segura y es susceptible de escuchas.

 Aplique SSL / TLS para transportar los canales que la aplicación móvil usará para transmitir
información delicada, tokens de sesión u otros datos confidenciales a una API de back-end o
servicio web.
 Tenga en cuenta las entidades externas, como compañías analíticas de terceros, redes
sociales, etc. mediante el uso de sus versiones SSL cuando una aplicación ejecuta una rutina
a través del navegador / webkit. Evite sesiones mixtas de SSL ya que pueden exponer la ID de
la sesión del usuario.
 Utilice los conjuntos de cifrado estándar de la industria con las longitudes de clave adecuadas.
 Use certificados firmados por un proveedor de CA de confianza.
 Nunca permita certificados autofirmados y considere la fijación de certificados para
aplicaciones de seguridad.
 Siempre requiere la verificación de la cadena SSL.
 Solo establezca una conexión segura después de verificar la identidad del servidor de punto
final utilizando certificados confiables en la cadena de claves.
 Avise a los usuarios a través de la interfaz de usuario si la aplicación móvil detecta un
certificado no válido.
 No envíe datos confidenciales a través de canales alternativos (p. Ej., SMS, MMS o
notificaciones).
 Si es posible, aplique una capa de cifrado por separado a cualquier dato sensible antes de que
se le dé al canal SSL. En el caso de que se descubran futuras vulnerabilidades en la
implementación de SSL, los datos cifrados proporcionarán una defensa secundaria contra la
violación de la confidencialidad.
Las amenazas más recientes permiten que un adversario espíe tráfico sensible interceptando el
tráfico dentro del dispositivo móvil justo antes de que la biblioteca SSL del dispositivo móvil
encripte y transmita el tráfico de la red al servidor de destino. Ver M10 para más información sobre
la naturaleza de este riesgo.
Mejores prácticas específicas de iOS
Las clases predeterminadas en la última versión de iOS manejan muy bien la negociación de
fuerza de cifrado SSL. El problema surge cuando los desarrolladores agregan código
temporalmente para eludir estos valores predeterminados para adaptarse a los obstáculos del
desarrollo. Además de las prácticas generales anteriores:
 Asegúrese de que los certificados sean válidos y fallen.

6-6-2018
 Cuando use CFNetwork, considere usar la API de transporte seguro para designar certificados
de clientes de confianza. En casi todas las situaciones, NSStreamSocketSecurityLevelTLSv1
se debe usar para mayor nivel de cifrado estándar.
 Después del desarrollo, asegúrese de que todas las llamadas NSURL (o envoltorios de
NSURL) no permitan certificados autofirmados o no válidos, como el método de clase NSURL
setAllowsAnyHTTPSCertificate.
 Considere el uso de fijación de certificados haciendo lo siguiente: exporte su certificado,
inclúyalo en su paquete de aplicaciones y fíjelo a su objeto de confianza. Usando la conexión
del método NSURL: willSendRequestForAuthenticationChallenge: ahora aceptará su
certificado.
Mejores prácticas específicas de Android
 Elimine todo el código después del ciclo de desarrollo que pueda permitir que la aplicación
acepte todos los certificados, como org.apache.http.conn.ssl.AllowAllHostnameVerifier o
SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. Estos son equivalentes a confiar en
todos los certificados.
 Si utiliza una clase que amplíe SSLSocketFactory, asegúrese de que el método
checkServerTrusted esté implementado correctamente para que el certificado del servidor esté
correctamente verificado.
M4 - Autenticación no segura. Esta categoría capta nociones de autenticación del usuario final o
gestión de sesión incorrecta. Esto puede incluir:
 No identificar al usuario en absoluto cuando eso debería ser requerido

 No mantener la identidad del usuario cuando se requiere
 Debilidades en la gestión de sesiones
Agentes de Vectores de Impactos

Debilidad de seguridad Impactos técnicos
amenaza ataque comerciales
Detectabilida Aplicación /
Aplicación Explotabilida Prevalenci
d Impacto SEVERO específico del
específica d FÁCIL a COMÚN
PROMEDIO negocio
Los agentes de Una vez que Los esquemas de El impacto técnico de El impacto
amenazas que el adversario autenticación pobres o la autenticación comercial de la
explotan las comprende faltantes permiten a un deficiente es que la autenticación
vulnerabilidade cómo el adversario ejecutar la solución no puede deficiente
s de esquema de funcionalidad de forma identificar al usuario normalmente
autenticación autenticación anónima dentro de la que realiza una dará como
suelen hacerlo es aplicación móvil o solicitud de resultado lo
a través de vulnerable, servidor de fondo acción. Inmediatament siguiente, como
ataques falsifica o utilizado por la aplicación e, la solución no podrá mínimo:
automatizados elude la móvil. La autenticación registrar o auditar la
que utilizan autenticación más débil para las actividad del usuario  Daño
herramientas enviando aplicaciones móviles es porque no se puede reputacional
6-6-2018
disponibles o solicitudes bastante frecuente establecer la identidad  Robo de

personalizadas de servicio al debido al factor de forma del usuario. Esto información;
. servidor de entrada de un contribuirá a la o
back-end de dispositivo móvil. El incapacidad de  Acceso no
la aplicación factor de forma fomenta detectar el origen de un autorizado a
móvil y omite altamente las ataque, la naturaleza los datos.
cualquier contraseñas cortas que a de cualquier exploits
interacción menudo se basan subyacente o cómo
directa con la exclusivamente en PIN prevenir futuros
aplicación de 4 dígitos. ataques.
móvil. Este
Los requisitos de Las fallas de
proceso de autenticación para autenticación también
envío aplicaciones móviles pueden exponer fallas
generalment pueden ser bastante de autorización
e se realiza a diferentes de los subyacentes. Cuando
través de esquemas de los controles de
malware autenticación web autenticación fallan, la
móvil dentro tradicionales debido a los solución no puede
del requisitos de verificar la identidad del
dispositivo o disponibilidad. usuario. Esta identidad
botnets
propiedad En las aplicaciones web está vinculada a la
función del usuario y
del atacante. tradicionales, se espera
los permisos
que los usuarios estén
en línea y se autentiquen asociados. Si un
atacante puede
en tiempo real con un
servidor de back-end. A ejecutar de manera
anónima la
lo largo de su sesión,
funcionalidad sensible,
existe una expectativa
resalta que el código
razonable de que
tendrán acceso continuo subyacente no verifica
los permisos del
a Internet.
usuario que emite la
En las aplicaciones solicitud para la
móviles, no se espera acción. Por lo tanto, la
que los usuarios estén ejecución anónima del
en línea en todo código resalta fallas en
momento durante su los controles de
sesión. Las conexiones a autenticación y
internet móvil son mucho autorización.
menos confiables o
predecibles que las
conexiones web
tradicionales. Por lo
tanto, las aplicaciones
móviles pueden tener
requisitos de tiempo de
actividad que requieren
6-6-2018
autenticación sin
conexión. Este requisito
fuera de línea puede
tener profundas
ramificaciones en cosas
que los desarrolladores
deben considerar al
implementar la
autenticación móvil.
Para detectar esquemas
de autenticación
deficientes, los
probadores pueden
realizar ataques binarios
contra la aplicación móvil
mientras está en modo
'fuera de línea'. A través
del ataque, el probador
forzará a la aplicación a
omitir la autenticación
fuera de línea y luego
ejecutará la funcionalidad
que debería requerir
autenticación fuera de
línea (para más
información sobre
ataques binarios, vea
M10). Además, los
probadores deberían
intentar ejecutar
cualquier funcionalidad
de servidor back-end de
forma anónima mediante
la eliminación de
cualquier token de sesión
de cualquier solicitud
POST / GET para la
funcionalidad de la
aplicación móvil.
¿Soy vulnerable a la "autenticación insegura"?
Hay muchas formas diferentes en que una aplicación móvil puede sufrir una autenticación
insegura:
 Si la aplicación móvil puede ejecutar anónimamente una solicitud de servicio API de back-end
sin proporcionar un token de acceso, esta aplicación adolece de una autenticación insegura;
6-6-2018
 Si la aplicación móvil almacena contraseñas o secretos compartidos localmente en el

dispositivo, lo más probable es que sufra una autenticación insegura;
 Si la aplicación móvil usa una política de contraseña débil para simplificar el ingreso de una
contraseña, adolece de una autenticación insegura; o
 Si la aplicación móvil usa una función como TouchID, sufre una autenticación insegura.
¿Cómo evito la 'Autenticación insegura'?

Evitar patrones débiles
Evite los siguientes patrones de diseño de autenticación de aplicaciones móviles inseguras:
 Si transfiere una aplicación web a su equivalente móvil, los requisitos de autenticación de las
aplicaciones móviles deben coincidir con los del componente de la aplicación web. Por lo tanto,
no debería ser posible autenticarse con menos factores de autenticación que el navegador
web;
 Autenticar a un usuario localmente puede conducir a vulnerabilidades de derivación del lado

del cliente. Si la aplicación almacena datos localmente, la rutina de autenticación puede
pasarse por alto en dispositivos jailbreak mediante la manipulación en tiempo de ejecución o la
modificación del binario. Si existe un requisito empresarial convincente para la autenticación
fuera de línea, consulte M10 para obtener orientación adicional sobre la prevención de ataques
binarios contra la aplicación móvil;
 Siempre que sea posible, asegúrese de que todas las solicitudes de autenticación se realicen
en el servidor. Tras la autenticación exitosa, los datos de la aplicación se cargarán en el
dispositivo móvil. Esto asegurará que los datos de la aplicación solo estarán disponibles
después de la autenticación exitosa;
 Si se requiere el almacenamiento de datos del lado del cliente, los datos deberán cifrarse
utilizando una clave de cifrado que se deriva de forma segura de las credenciales de inicio de
sesión del usuario. Esto asegurará que los datos almacenados de la aplicación solo serán
accesibles al ingresar exitosamente las credenciales correctas. Existen riesgos adicionales de
que los datos se descifrarán a través de ataques binarios. Consulte M9 para obtener
orientación adicional sobre la prevención de ataques binarios que conducen al robo de datos
locales;
 La funcionalidad de autenticación persistente (Remember Me) implementada en aplicaciones

móviles nunca debe almacenar la contraseña de un usuario en el dispositivo;
 Idealmente, las aplicaciones móviles deberían utilizar un token de autenticación específico del
dispositivo que el usuario puede revocar dentro de la aplicación móvil. Esto asegurará que la
aplicación pueda mitigar el acceso no autorizado desde un dispositivo robado / perdido;
 No use ningún valor spoof-able para autenticar a un usuario. Esto incluye identificadores de
dispositivos o geolocalización;
6-6-2018
 La autenticación persistente dentro de las aplicaciones móviles debe implementarse como opt-
in y no habilitarse por defecto;
 Si es posible, no permita que los usuarios proporcionen números PIN de 4 dígitos para las
contraseñas de autenticación.
Reforzar la autenticación
 Los desarrolladores deben asumir toda la autorización del lado del cliente y los usuarios
malintencionados pueden pasar por alto los controles de autenticación. Los controles de
autorización y autenticación deben volver a aplicarse en el lado del servidor siempre que sea
posible.
 Debido a los requisitos de uso fuera de línea, es posible que se requiera que las aplicaciones
móviles realicen comprobaciones locales de autenticación o autorización dentro del código de
la aplicación móvil. Si este es el caso, los desarrolladores deben instrumentar comprobaciones
de integridad local dentro de su código para detectar cualquier cambio de código no
autorizado. Consulte M9 para obtener más información sobre cómo detectar y reaccionar ante
ataques binarios.
o M5 - Criptografía insuficiente. El código aplica criptografía a un activo de información

sensible. Sin embargo, la criptografía es insuficiente de alguna manera. Tenga en cuenta que
todo lo relacionado con TLS o SSL va en M3. Además, si la aplicación no puede usar la
criptografía cuando debería, eso probablemente pertenece a M2. Esta categoría es para los
problemas donde se intentó la criptografía, pero no se realizó correctamente.

Aplicación /
específico del
negocio
Los agentes Los vectores Con el fin de explotar esta Esta Esta
de amenazas de ataque debilidad, un adversario debe vulnerabilidad vulnerabilidad
incluyen lo incluyen lo devolver el código cifrado o los dará como puede tener
siguiente: siguiente: datos confidenciales a su forma resultado la varios impactos
cualquier descifrado de descifrada original debido a recuperación comerciales
persona con datos a través algoritmos de cifrado débiles o no autorizada diferentes. Por lo
acceso físico a del acceso fallas dentro del proceso de de información general, la
datos cifrados físico al cifrado. sensible desde criptografía rota
de forma dispositivo o el dispositivo dará como
incorrecta o captura de móvil. resultado lo
malware móvil tráfico de red, siguiente:
que actúa en o aplicaciones
nombre del maliciosas en  Violaciones
adversario. el dispositivo de
con acceso a privacidad;
6-6-2018
los datos  Robo de

encriptados. información;
 Robo de
código;
 Robo de
propiedad
intelectual; o
 Daño
reputacional
¿Soy vulnerable a la "criptografía insuficiente"?
El uso inseguro de la criptografía es común en la mayoría de las aplicaciones móviles que
aprovechan el cifrado. Hay dos formas fundamentales de que la criptografía rota se manifieste en
las aplicaciones móviles. Primero, la aplicación móvil puede usar un proceso detrás del cifrado /
descifrado que es fundamentalmente defectuoso y puede ser explotado por el adversario para
descifrar datos confidenciales. En segundo lugar, la aplicación móvil puede implementar o
aprovechar un algoritmo de cifrado / descifrado que es de naturaleza débil y puede ser descifrado
directamente por el adversario. Las siguientes subsecciones exploran estos dos escenarios con
más profundidad:
Confianza en los procesos de encriptación de códigos incorporados

Por defecto, las aplicaciones de iOS están protegidas (en teoría) de ingeniería inversa a través de
encriptación de código. El modelo de seguridad de iOS requiere que las aplicaciones sean
encriptadas y firmadas por fuentes confiables para poder ejecutarlas en entornos que no son de
jailbreak. Tras la puesta en marcha, el cargador de la aplicación iOS descifrará la aplicación en la
memoria y procederá a ejecutar el código una vez que iOS haya verificado su firma. Esta
característica, en teoría, evita que un atacante realice ataques binarios contra una aplicación móvil
iOS.
Utilizando herramientas disponibles libremente como ClutchMod o GBD, un adversario descargará
la aplicación cifrada en su dispositivo liberado y tomará una instantánea de la aplicación
descifrada una vez que el cargador de iOS la cargue en la memoria y la descifre (justo antes de
que el cargador inicie la ejecución). Una vez que el adversario toma la instantánea y la almacena
en el disco, el adversario puede usar herramientas como IDA Pro o Hopper para realizar
fácilmente un análisis estático / dinámico de la aplicación y realizar más ataques binarios.
Pasar por alto los algoritmos de cifrado de código incorporado es, en el mejor de los casos,
trivial. Siempre suponga que un adversario podrá evitar cualquier cifrado de código incorporado
ofrecido por el SO móvil subyacente. Para obtener más información acerca de los pasos
adicionales que puede realizar para proporcionar capas adicionales de prevención de ingeniería
inversa, consulte M9.
Procesos deficientes de gestión de claves
Los mejores algoritmos no importan si manipulas mal tus llaves. Muchos cometen el error de usar
el algoritmo de cifrado correcto, pero implementan su propio protocolo para emplearlo. Algunos
ejemplos de problemas aquí incluyen:
 Incluir las claves en el mismo directorio legible por el atacante que el contenido encriptado;
6-6-2018
 Hacer que las llaves estén disponibles para el atacante;

 Evite el uso de claves codificadas dentro de su binario; y
 Las claves pueden ser interceptadas a través de ataques binarios. Consulte M10 para obtener
más información sobre la prevención de ataques binarios.
Creación y uso de protocolos de encriptación personalizados
No hay una manera más fácil de manejar mal el cifrado, ya sea móvil o de otro tipo, que tratar de
crear y usar sus propios algoritmos o protocolos de cifrado.
Utilice siempre algoritmos modernos que la comunidad de seguridad acepte como fuertes y,
siempre que sea posible, aproveche las API de cifrado de vanguardia dentro de su plataforma
móvil. Los ataques binarios pueden hacer que el adversario identifique las bibliotecas comunes
que ha usado junto con las claves codificadas en el binario. En casos de requisitos de seguridad
muy altos en torno al cifrado, debe considerar seriamente el uso de la criptografía de
whitebox. Consulte M10 para obtener más información sobre la prevención de ataques binarios
que podrían llevar a la explotación de bibliotecas comunes.
Uso de Algoritmos Inseguros y / o Desaprobados
Muchos algoritmos y protocolos criptográficos no deben utilizarse porque se ha demostrado que
tienen debilidades importantes o son insuficientes para los requisitos de seguridad
modernos. Éstas incluyen:
 RC2
 MD4
 MD5
 SHA1
¿Cómo evito la "criptografía insuficiente"?
Lo mejor es hacer lo siguiente al manejar datos confidenciales:
 Evite el almacenamiento de datos confidenciales en un dispositivo móvil cuando sea posible.

 Aplicar estándares criptográficos que resistan la prueba del tiempo durante al menos 10 años
en el futuro; y
 Siga las pautas del NIST sobre los algoritmos recomendados (vea referencias externas).
M6 – Autorización insegura. Esta es una categoría para capturar cualquier falla en la
autorización (por ejemplo, decisiones de autorización en el lado del cliente, navegación forzada,
etc.). Es distinto de los problemas de autenticación (por ejemplo, la inscripción del dispositivo, la
identificación del usuario, etc.).
Si la aplicación no autentica a los usuarios en una situación en la que debería (por ejemplo,
otorgar acceso anónimo a algún recurso o servicio cuando se autentica y se requiere acceso
autorizado), entonces se trata de una falla de autenticación, no de una falla de autorización.
Aplicación /
específico del
negocio
6-6-2018
Los agentes de Una vez que el Para probar esquemas de El impacto En el caso de
amenazas que adversario autorización deficientes, técnico de una que un usuario
explotan las comprende cómo el los probadores pueden autorización (anónimo o
vulnerabilidades esquema de realizar ataques binarios deficiente es verificado) pueda
de autorización autorización es contra la aplicación móvil de naturaleza ejecutar una
suelen hacerlo a vulnerable, inicia e intentar ejecutar similar al funcionalidad
través de sesión en la funciones privilegiadas impacto con exceso de
ataques aplicación como un que solo deberían ser técnico de la privilegios, la
automatizados usuario ejecutables con un usuario autenticación empresa puede
que utilizan legítimo. Pasaron de mayor privilegio deficiente. El experimentar los
herramientas con éxito el control mientras la aplicación impacto siguientes
disponibles o de móvil está en modo 'fuera técnico puede impactos:
personalizadas. autenticación. Una de línea' (para obtener ser de gran
vez que se ha más información sobre alcance en  Daño
pasado la ataques binarios, ver M9 y naturaleza y reputacional;
autenticación, por M10). Además, los depende de la  Fraude; o
lo general, fuerzan probadores deberían naturaleza de  Robo de
la búsqueda a un intentar ejecutar cualquier la información
punto vulnerable funcionalidad privilegiada funcionalidad
para ejecutar la usando un token de sesión sobreexcitada
funcionalidad de bajo privilegio dentro que se
administrativa. Este de las correspondientes ejecuta. Por
proceso de envío solicitudes POST / GET ejemplo, la
generalmente se para la funcionalidad ejecución con
realiza a través de sensible al servidor privilegios
malware móvil backend. Los esquemas excesivos de
dentro del de autorización escasos o la
dispositivo o faltantes permiten a un funcionalidad
botnets propiedad adversario ejecutar de
del atacante. funcionalidades a las que administración
no deberían tener remota o local
derecho. a usar un usuario puede
autenticado pero con provocar la
privilegios inferiores de la destrucción de
aplicación móvil. Los sistemas o el
requisitos de autorización acceso a
son más vulnerables al información
tomar decisiones de confidencial.
autorización dentro del
dispositivo móvil en lugar
de a través de un servidor
remoto.
¿Soy vulnerable a la "autorización insegura"?
Es importante reconocer la diferencia entre autenticación y autorización. Autenticación es el acto
de identificar a un individuo. La autorización es el acto de verificar que la persona identificada
tenga los permisos necesarios para realizar el acto. Los dos están estrechamente relacionados ya
6-6-2018
que las verificaciones de autorización siempre deben seguir inmediatamente a la autenticación de

una solicitud entrante desde un dispositivo móvil.
Si una organización no puede autenticarse e individualmente antes de ejecutar un punto final API
solicitado desde un dispositivo móvil, entonces el código también sufre automáticamente de una
autorización insegura. Es esencialmente imposible que se realicen comprobaciones de
autorización en una solicitud entrante cuando la identidad de la persona que llama no está
establecida.
Hay algunas reglas fáciles de seguir cuando se intenta determinar si un punto final móvil sufre una
autorización insegura:
 Presencia de vulnerabilidades inseguras de referencia directa de objeto (IDOR) : si ve

una vulnerabilidad de referencia de objeto directa insegura (IDOR), es muy probable que el
código no realice una verificación de autorización válida; y
 Puntos finales ocultos : por lo general, los desarrolladores no realizan comprobaciones de

autorización en la funcionalidad oculta de back-end ya que suponen que la funcionalidad oculta
solo la verá alguien con el rol correcto;
 Funciones de usuario o transmisiones de permisos : si la aplicación móvil está

transmitiendo los roles o permisos del usuario a un sistema de back-end como parte de una
solicitud, está sufriendo de una autorización insegura.
¿Cómo evito la "autorización insegura"?
Para evitar controles de autorización inseguros, haga lo siguiente:
 Verifique los roles y permisos del usuario autenticado usando solo la información contenida en
los sistemas back-end. Evite confiar en cualquier rol o información de permiso que provenga
del dispositivo móvil en sí mismo;
 El código de back-end debe verificar de forma independiente que los identificadores entrantes
asociados con una solicitud (operandos de una operación solicitada) que aparezcan junto con
la identificación coincidan y pertenezcan a la identidad entrante
o M7 - Calidad del código cliente. Esta fue la "Decisiones de seguridad a través de insumos
no confiables", una de nuestras categorías menos utilizadas. Esta sería la solución para los
problemas de implementación a nivel de código en el cliente móvil. Eso es distinto de los
errores de codificación del lado del servidor. Esto capturaría cosas 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 ejecuta en el dispositivo móvil.

6-6-2018
Aplicación /
específico del
específica DIFICIL COMÚN DIFÍCIL MODERADO
negocio
Los Agentes de Un atacante Los problemas de calidad La mayoría de El impacto
amenaza típicamente del código son bastante las explotaciones comercial de
incluyen explotará las frecuentes en la mayoría que entran en esta categoría
entidades que vulnerabilidades de los códigos móviles. La esta categoría de
pueden pasar en esta buena noticia es que la dan como vulnerabilidades
entradas no categoría mayoría de los problemas resultado la varía mucho,
confiables a mediante el de calidad del código son ejecución de dependiendo de
llamadas de suministro de bastante benignos y dan código extraño o la naturaleza del
método entradas como resultado una mala la denegación de exploit. Los
realizadas dentro cuidadosamente práctica de servicio en los problemas de
del código diseñadas a la programación. Por lo puntos finales calidad de
móvil. Este tipo víctima. Estas general, es difícil detectar del servidor código deficiente
de problemas no entradas se este tipo de problemas remoto (y no en que dan como
son pasan al código mediante la revisión el dispositivo resultado la
necesariamente que reside manual del código. En móvil en sí). Sin ejecución
problemas de dentro del cambio, los atacantes embargo, en remota de
seguridad en sí dispositivo móvil utilizarán herramientas de caso de que código podrían
mismos, sino donde se lleva a terceros que realizan existan generar los
que generan cabo la análisis estáticos o desbordamientos siguientes
vulnerabilidades explotación. Los realizan fuzzing. Este tipo / impactos
de tipos típicos de de herramientas desbordamientos comerciales:
seguridad. Por ataques típicamente identificará del búfer dentro
ejemplo, los explotarán fugas fugas de memoria, del dispositivo  Robo de
desbordamientos de memoria y desbordamientos de búfer móvil y la información;
de búfer en las desbordamientos y otros problemas menos entrada se  Daño
versiones de búfer. graves que dan como puede derivar de reputacional;
anteriores de resultado una mala un tercero  Robo de
Safari (una práctica de externo, esto Propiedad
vulnerabilidad de programación. Los piratas podría tener un Intelectual
calidad de informáticos con un nivel impacto técnico
código extremadamente bajo de gravemente alto Otros problemas
deficiente) conocimiento y y debería técnicos menos
provocaron experiencia son capaces remediarse. graves que
ataques de explotar con eficacia entran en esta
Jailbreak de alto este tipo de problemas. El categoría
riesgo y paso a objetivo principal típico es pueden provocar
paso. Los ejecutar código extraño degradaciones
problemas dentro del espacio de en el
deficientes en la direcciones del código rendimiento, el
calidad del móvil. uso de memoria
código suelen o una
explotarse a arquitectura de
través de estafas front-end pobre.
6-6-2018
de malware o
phishing.
¿Soy vulnerable a la "calidad de código deficiente"?
Esta es la solución general para los problemas de implementación a nivel de código en el cliente
móvil. Eso es distinto de los errores de codificación del lado del servidor. Esto captura 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 ejecuta en el dispositivo móvil.
Esto es distinto del uso inadecuado de la plataforma porque generalmente se refiere al lenguaje
de programación en sí (p. Ej., Java, Swift, Objective C, JavaScript). Un desbordamiento de búfer
en C o un XSS basado en DOM en una aplicación móvil Webview sería problemas de calidad del
código.
La característica clave de este riesgo es que se trata de un código que se ejecuta en el dispositivo
móvil y el código debe cambiarse de manera bastante localizada. La reparación de la mayoría de
los riesgos requiere cambios de código, pero en el caso de la calidad del código, el riesgo
proviene de usar la API incorrecta, utilizar una API de forma insegura, usar construcciones de
lenguaje inseguro o algún otro problema de nivel de código. Es importante destacar que no se
trata de un código que se ejecuta en el servidor. Este es un riesgo que captura el código incorrecto
que se ejecuta en el dispositivo móvil.
¿Cómo evito la 'mala calidad del código'?
En general, los problemas de calidad del código pueden evitarse haciendo lo siguiente:
 Mantener patrones de codificación consistentes en los que todos en la organización estén de

acuerdo;
 Escribir un código que sea fácil de leer y bien documentado;
 Cuando utilice almacenamientos intermedios, valide siempre que las longitudes de cualquier
información del búfer entrante no excederán la longitud del búfer de destino;
 A través de la automatización, identifique los desbordamientos del búfer y las pérdidas de
memoria mediante el uso de herramientas de análisis estáticos de terceros; y
 Priorice resolver los desbordamientos del búfer y las pérdidas de memoria sobre otros
problemas de "calidad del código".
o M8 – Manipulacion del Código .Esta categoría cubre el parche binario, la modificación de

recursos locales, el enganche de métodos, el swizzling de métodos y la modificación de
memoria dinámica.
Una vez que la aplicación se entrega al dispositivo móvil, el código y los recursos de datos residen
allí. Un atacante puede modificar directamente el código, cambiar los contenidos de la memoria de
forma dinámica, cambiar o reemplazar las API del sistema que utiliza la aplicación o modificar los
datos y recursos de la aplicación. Esto puede proporcionar al atacante un método directo para
subvertir el uso previsto del software para obtener ganancias personales o monetarias.
6-6-2018
Aplicación /
específico del
negocio
Normalmente, Normalmente, Las formas modificadas de El impacto de laEl impacto
un atacante un atacante las aplicaciones son modificación delcomercial de la
aprovechará hará lo sorprendentemente más código puede modificación del
la siguiente para comunes de lo que ser de amplio código
modificación explotar esta piensas.Existe toda una alcance, generalmente
del código a categoría: industria de seguridad creada dependiendo de resulta en lo
través de para detectar y eliminar la naturaleza desiguiente:
formas  Realice versiones no autorizadas de la modificación
maliciosas de cambios aplicaciones móviles dentro en sí misma.Los  Pérdida de
las binarios de las tiendas de tipos típicos de ingresos
aplicaciones directos en aplicaciones. Dependiendo impactos debido a la
alojadas en el binario del enfoque adoptado para incluyen los piratería; o
tiendas de del núcleo resolver el problema de la siguientes:  Daño
aplicaciones de la detección de modificación de reputacional
de terceros. El aplicación código, las organizaciones  Nuevas
atacante  Realice pueden tener formas limitadas funciones no
también cambios a altamente exitosas de autorizadas;
puede binarios detectar versiones no  El robo de
engañar al directos a autorizadas de código en la identidad; o
usuario para los naturaleza.  Fraude.
que instale la recursos Esta categoría cubre el
aplicación a dentro del parche binario, la
través de paquete del modificación de recursos
ataques de aplicativo locales, el enganche de
phishing.  Redirige o métodos, el swizzling de
reemplaza métodos y la modificación de
las API del memoria dinámica.
sistema
para Una vez que la aplicación se
interceptar entrega al dispositivo móvil, el
y ejecutar código y los recursos de
código datos residen allí. Un
extraño que atacante puede modificar
es directamente el código,
malicioso cambiar los contenidos de la
memoria de forma dinámica,
cambiar o reemplazar las API
del sistema que utiliza la
aplicación o modificar los
datos y recursos de la
aplicación. Esto puede
proporcionar al atacante un
método directo para subvertir
el uso previsto del software
6-6-2018
para obtener ganancias

personales o monetarias.
¿Soy vulnerable al 'Código Manipulación'?

Técnicamente, todo el código móvil es vulnerable a la alteración del código. El código móvil se
ejecuta dentro de un entorno que no está bajo el control de la organización que produce el
código. Al mismo tiempo, hay muchas formas diferentes de alterar el entorno en el que se ejecuta
ese código. Estos cambios permiten que un adversario toque el código y lo modifique a voluntad.
Aunque el código móvil es intrínsecamente vulnerable, es importante preguntarse si vale la pena
detectarlo e intentar prevenir la modificación no autorizada del código. Las aplicaciones escritas
para ciertos negocios verticales (juegos por ejemplo) son mucho más vulnerables a los impactos
de la modificación del código que otras (hospitalidad, por ejemplo). Como tal, es fundamental
considerar el impacto del negocio antes de decidir si se aborda o no este riesgo.
¿Cómo evito la "alteración de código"?
La aplicación móvil debe ser capaz de detectar en tiempo de ejecución que el código se ha
agregado o cambiado de lo que sabe sobre su integridad en tiempo de compilación. La aplicación
debe poder reaccionar adecuadamente en tiempo de ejecución a una violación de la integridad del
código.
Las estrategias de remediación para este tipo de riesgo se describen con más detalle técnico
dentro del Proyecto de Prevención de Modificación de Código e Ingeniería Reversa de OWASP .
Android Root Detection
Normalmente, una aplicación que se ha modificado se ejecutará dentro de un entorno Jailbroken o
rooteado. Como tal, es razonable tratar de detectar este tipo de entornos comprometidos en
tiempo de ejecución y reaccionar en consecuencia (informar al servidor o apagarlo). Hay algunas
formas comunes de detectar un dispositivo Android rooteado: buscar claves de prueba
 Compruebe si build.prop incluye la línea ro.build.tags = test-keys que indica una compilación
del desarrollador o una ROM no oficial
Verificar certificados OTA
 Compruebe si el archivo /etc/security/otacerts.zip existe

Compruebe si hay apk de raíz conocidos
 com.noshufou.android.su
 com.thirdparty.superuser
 eu.chainfire.supersu
 com.koushikdutta.superuser
Verifique los binarios de SU
6-6-2018
 / system / bin / su
 / system / xbin / su
 / sbin / su
 / system / su
 /system/bin/.ext/.su
Intento de comando SU directamente
 Intente ejecutar el comando su y verifique la identificación del usuario actual, si devuelve 0,

entonces el comando su ha sido exitoso
o M9 - Ingeniería inversa. Esta categoría incluye el análisis del núcleo binario final para
determinar su código fuente, bibliotecas, algoritmos y otros activos. Software como IDA Pro,
Hopper, otool y otras herramientas de inspección binaria le dan al atacante una idea del
funcionamiento interno de la aplicación. Esto se puede usar para explotar otras
vulnerabilidades incipientes en la aplicación, así como también para revelar información acerca
de los servidores back-end, las constantes y cifrados criptográficos y la propiedad intelectual.
Agentes de Vectores de Impactos

Debilidad de seguridad Impactos técnicos
amenaza ataque comerciales
Aplicación /
específico del
específica FÁCIL COMÚN FÁCIL MODERADO
negocio
Un atacante Un atacante Generalmente, todo el Un atacante puede Los impactos
normalmente debe realizar código móvil es susceptible explotar la comerciales de la
descargará la un análisis del de ingeniería ingeniería inversa ingeniería inversa
aplicación binario central inversa. Algunas para lograr son bastante
específica de final para aplicaciones son más cualquiera de los variados. Incluyen
una tienda de determinar su susceptibles que otras. El siguientes: lo siguiente:
aplicaciones tabla de código escrito en lenguajes
y la analizará cadenas / marcos que permiten la  Revelar  Robo de
dentro de su original, introspección dinámica en información propiedad
propio código fuente, tiempo de ejecución (Java, sobre intelectual;
entorno local bibliotecas, .NET, Objective C, Swift) servidores  Daño
utilizando un algoritmos y están particularmente en back-end; reputacional;
conjunto de recursos riesgo de ingeniería  Revelar  El robo de
herramientas integrados en inversa. La detección de la constantes identidad; o
diferentes. la susceptibilidad a la criptográficas y  Compromiso
aplicación.Los ingeniería inversa es cifrados; de los
atacantes bastante sencilla. Primero,  Robar sistemas back-
utilizarán descifre la versión de la propiedad end.
herramientas aplicación de la tienda de intelectual;
relativamente aplicaciones (si se aplica el  Realizar
asequibles y cifrado binario). Luego, use ataques contra
bien las herramientas descritas sistemas de
entendidas en la sección "Vectores de back-end; o
6-6-2018
como IDA Pro, ataque" de este documento  Obtenga la

Hopper, otool, contra el binario. El código inteligencia
cadenas y será susceptible si es necesaria para
otras bastante fácil de entender realizar
herramientas la ruta de control de flujo modificaciones
de inspección de la aplicación, la tabla de de código
binaria desde cadenas y cualquier subsiguientes.
el entorno del pseudocódigo / código
atacante. fuente generado por estas
herramientas.
¿Soy vulnerable a la "ingeniería inversa"?
En general, la mayoría de las aplicaciones son susceptibles de ingeniería inversa debido a la
naturaleza inherente del código. La mayoría de los lenguajes utilizados para escribir aplicaciones
hoy en día son ricos en metadatos que ayudan enormemente a un programador a depurar la
aplicación. Esta misma capacidad también ayuda a un atacante a comprender cómo funciona la
aplicación.
Se dice que una aplicación es susceptible de ingeniería inversa si un atacante puede hacer
cualquiera de las siguientes cosas:
 Entender claramente el contenido de la tabla de cadenas de un binario

 Realizar con precisión el análisis multifuncional
 Derive una recreación razonablemente precisa del código fuente del binario
Aunque la mayoría de las aplicaciones son susceptibles de ingeniería inversa, es importante

examinar el impacto comercial potencial de la ingeniería inversa cuando se considera si mitigar
este riesgo o no. Vea los ejemplos a continuación para una pequeña muestra de lo que se
puede hacer con ingeniería inversa por sí solo.
¿Cómo evito la "ingeniería inversa"?

Para evitar una ingeniería inversa efectiva, debe usar una herramienta de ofuscación. Hay muchos
ofuscadores de grado libre y comercial en el mercado. Por el contrario, hay muchos difusores
diferentes en el mercado. Para medir la efectividad de cualquier herramienta de ofuscación que
elija, intente desofuscar el código usando herramientas como IDA Pro y Hopper.
Un buen ofuscador tendrá las siguientes habilidades:
 Restrinja qué métodos / segmentos de código ofuscar;
 Ajustar el grado de ofuscación para equilibrar el impacto en el rendimiento;
 Resista a la desconfusión de herramientas como IDA Pro y Hopper;
6-6-2018
o M10 – Funcionalidad Extraña. Esta categoría incluye el análisis del núcleo binario final para
determinar su código fuente, bibliotecas, algoritmos y otros activos. Software como IDA Pro,
Hopper, otool y otras herramientas de inspección binaria le dan al atacante una idea del
funcionamiento interno de la aplicación. Esto se puede usar para explotar otras
vulnerabilidades incipientes en la aplicación, así como también para revelar información acerca
de los servidores back-end, las constantes y cifrados criptográficos y la propiedad intelectual.
Agentes de Impactos Impactos

Vectores de ataque Debilidad de seguridad
amenaza técnicos comerciales
Aplicación /
Aplicación Prevalencia Detectabilidad Impacto
Explotabilidad FÁCIL específico del
específica COMÚN PROMEDIO SEVERO
negocio
Por lo Un atacante Existe una alta El impacto El impacto
general, un descargará y probabilidad de que una técnico de la comercial de la
atacante examinará la aplicación móvil funcionalidad funcionalidad
intenta aplicación móvil determinada contenga externa incluye externa incluye lo
comprender dentro de su propio una funcionalidad extraña lo siguiente: siguiente:
la entorno que no esté directamente
funcionalidad local. Examinarán los expuesta al usuario a  Exposición  Acceso no
externa archivos de registro, través de la interfaz. La de cómo autorizado a la
dentro de los archivos de mayoría de este código funcionan funcionalidad
una configuración y tal adicional es de naturaleza los sensible;
aplicación vez el propio binario benigna y no le dará a un sistemas  Daño
móvil para para descubrir los atacante ningún back-end; o reputacional; o
descubrir la switches ocultos o el conocimiento adicional  Acciones  Robo de
funcionalidad código de prueba sobre las capacidades de no Propiedad
oculta en los que dejaron los back-end. Sin embargo, autorizadas Intelectual
sistemas desarrolladores. Ellos algunas funciones de alto
back-end. El explotarán estos extrañas pueden ser muy privilegio
atacante interruptores y la útiles para un ejecutadas.
normalmente funcionalidad oculta atacante. La funcionalidad
explotará la en el sistema back- que expone la información
funcionalidad end para realizar un relacionada con la prueba
externa ataque. de back-end, demo,
directamente staging o entornos UAT
desde sus no debe incluirse en una
propios compilación de
sistemas sin producción. Además, los
6-6-2018
la puntos finales
participación administrativos API o
de los puntos finales no oficiales
usuarios no deberían incluirse en
finales. las construcciones finales
de producción. Detectar
una funcionalidad extraña
puede ser
complicado. Las
herramientas automáticas
de análisis estático y
dinámico pueden recoger
fruta de bajo costo
(declaraciones de
registro). Sin embargo,
algunas puertas traseras
son difíciles de detectar
de manera
automatizada.Como tal,
¿Soy vulnerable a la "funcionalidad extraña"?
A menudo, los desarrolladores incluyen funciones ocultas de puerta trasera u otros controles
internos de seguridad de desarrollo que no están destinados a ser lanzados a un entorno de
producción. Por ejemplo, un desarrollador puede incluir accidentalmente una contraseña como
comentario en una aplicación híbrida. Otro ejemplo incluye la desactivación de la autenticación de
2 factores durante la prueba.
La característica definitoria de este riesgo es dejar la funcionalidad habilitada en la aplicación que
no estaba destinada a ser lanzada.
¿Cómo evito la "funcionalidad extraña"?
La mejor forma de prevenir esta vulnerabilidad es llevar a cabo una revisión manual del código de
seguridad usando los campeones de seguridad o los expertos en la materia más conocedores de
este código. Deberían hacer lo siguiente:
1. Examine la configuración de la aplicación para descubrir cualquier interruptor oculto;

2. Verifique que todos los códigos de prueba no estén incluidos en la compilación de
producción final de la aplicación;
3. Examine todos los puntos finales API a los que accede la aplicación móvil para verificar que
estos puntos finales estén bien documentados y estén disponibles públicamente;
4. Examine todas las instrucciones de registro para asegurarse de que no haya nada
demasiado descriptivo sobre el backend que se está escribiendo en los registros.
6-6-2018
Los 10 mejores controles móviles

Colaboración OWASP / ENISA
OWASP y la Agencia Europea de Seguridad de Redes e Información (ENISA) colaboraron para
construir un conjunto conjunto de controles. ENISA ha publicado los resultados del esfuerzo de
colaboración como la "Guía de desarrollo seguro para teléfonos inteligentes".
1. Identificar y proteger datos confidenciales en el dispositivo móvil

Riesgos: almacenamiento de datos confidenciales no seguros, ataques a teléfonos retirados de servicio
divulgación involuntaria: dispositivos móviles (que son móviles) tienen un mayor riesgo de pérdida o robo.
Se debe incorporar una protección adecuada para minimizar la pérdida de datos confidenciales en el
dispositivo.
1.1 En la fase de diseño, clasifique el almacenamiento de datos de acuerdo con la sensibilidad y aplique los
controles correspondientes (por ejemplo, contraseñas, datos personales, ubicación, registros de errores,
etc.). Procese, almacene y use datos de acuerdo con su clasificación. Valide la seguridad de las llamadas
API aplicadas a datos confidenciales.
1.2 Almacenar datos confidenciales en el servidor en lugar del dispositivo del cliente final. Esto se basa en
la suposición de que la conectividad de red segura está suficientemente disponible y que los mecanismos
de protección disponibles para el almacenamiento del lado del servidor son superiores. La seguridad
relativa de la seguridad del cliente frente al lado del servidor también debe evaluarse caso por caso
(consulte ENISA evaluación de riesgo en la nube (3) o la Nube de OWASP top 10 (4) para soporte de
decisiones).
1.3 Al almacenar datos en el dispositivo, use una API de cifrado de archivos proporcionada por el sistema
operativo u otra fuente confiable. Algunas plataformas proporcionan API de cifrado de archivos que utilizan
una clave secreta protegida por el código de desbloqueo del dispositivo y se pueden eliminar en la
eliminación remota. Si esto está disponible, debe usarse ya que aumenta la seguridad del cifrado sin crear
6-6-2018
una carga adicional para el usuario final. También hace que los datos almacenados sean más seguros en
caso de pérdida o robo. Sin embargo, debe tenerse en cuenta que incluso cuando está protegido por la
llave de desbloqueo del dispositivo, si los datos están almacenados en el dispositivo, su seguridad depende
de la seguridad del código de desbloqueo del dispositivo si la eliminación remota de la clave es por alguna
razón imposible .
1.4 No almacene / almacene datos confidenciales (incluidas las claves) a menos que estén encriptados y si
es posible almacenados en un área a prueba de manipulaciones (vea el control 2).
1.5 Considere restringir el acceso a datos confidenciales basados en información contextual, como la
ubicación (por ejemplo, la aplicación de billetera no se puede usar si los datos del GPS muestran que el
teléfono está fuera de Europa, la llave del auto no se puede usar a menos que estén dentro de 100m de
auto, etc.).
1.6 No almacene el GPS histórico / rastreo u otra información confidencial en el dispositivo más allá del
período requerido por la aplicación (ver controles 1.7, 1.8).
1.7 Suponga que el almacenamiento compartido no es de confianza: la información puede filtrarse
fácilmente de forma inesperada a través de cualquier almacenamiento compartido. En particular:
Tenga en cuenta las cachés y el almacenamiento temporal como un posible canal de fuga, cuando se
comparte con otras aplicaciones.
Tenga en cuenta que el almacenamiento compartido público, como la libreta de direcciones, la galería
multimedia y los archivos de audio, es un posible canal de fuga. Por ejemplo, el almacenamiento de
imágenes con metadatos de ubicación en la galería multimedia permite que esa información se comparta
de forma involuntaria.
No almacene datos temporales / en caché en un directorio legible por todo el mundo.
1.8 Para datos personales confidenciales, la eliminación debe programarse de acuerdo con un período de
retención máximo (para evitar, por ejemplo, que los datos permanezcan en cachés indefinidamente).
1.9 Actualmente no existe un procedimiento estándar de eliminación segura para la memoria flash (a
menos que se limpie todo el medio / tarjeta). Por lo tanto, el cifrado de datos y la administración segura de
claves son especialmente importantes.
1.10 Considere la seguridad de todo el ciclo de vida de los datos al escribir su aplicación (recopilación por
cable, almacenamiento temporal, almacenamiento en caché, copia de seguridad, eliminación, etc.)
1.11 Aplicar el principio de divulgación mínima: solo recopilar y divulgar los datos que se requieren para el
uso empresarial de la aplicación. Identifique en la fase de diseño qué datos se necesitan, su sensibilidad y
si es apropiado recopilar, almacenar y usar cada tipo de datos.
1.12 Utilice identificadores no persistentes que no se compartan con otras aplicaciones siempre que sea
posible; por ejemplo, no use el número de identificación del dispositivo como identificador a menos que
haya una buena razón para hacerlo (use un número generado aleatoriamente, consulte 4.3). Aplique los
mismos principios de minimización de datos a las sesiones de la aplicación que a las sesiones de http /
cookies, etc.
1.13 Las aplicaciones en los dispositivos administrados deben utilizar las API de conmutación de borrado y
eliminación remotas para eliminar información confidencial del dispositivo en caso de robo o pérdida. (Un
6-6-2018
kill-switch es el término utilizado para un nivel OS o un medio creado especialmente para eliminar
remotamente aplicaciones y / o datos).
1.14 Los desarrolladores de aplicaciones pueden desear incorporar un "interruptor de eliminación de datos"
específico de la aplicación en sus productos, para permitir la eliminación por aplicación de los datos
confidenciales de la aplicación cuando sea necesario (se requiere una autenticación fuerte para proteger el
uso indebido de dicha característica).
2. Manejar las credenciales de contraseña de forma segura en el dispositivo

Riesgos: Spyware, vigilancia, malware financiero. Las credenciales de un usuario, si son robadas, no solo
proporcionan acceso no autorizado al servicio de back-end móvil, sino que también pueden comprometer
muchos otros servicios y cuentas utilizados por el usuario. El riesgo aumenta debido a la generalización de
la reutilización de contraseñas en diferentes servicios.
2.1 En lugar de contraseñas, considere utilizar tokens de autorización a más largo plazo que puedan
almacenarse de forma segura en el dispositivo (según el modelo OAuth). Encripte los tokens en tránsito
(usando SSL / TLS). Los tokens pueden ser emitidos por el servicio back-end después de verificar
Los teléfonos inteligentes protegen las pautas de desarrollo para los desarrolladores de aplicaciones la
credencial del usuario inicialmente. Los tokens deben tener un límite de tiempo para el servicio específico y
revocable (si es posible del lado del servidor), lo que minimiza el daño en los escenarios de pérdida. Utilice
las últimas versiones de los estándares de autorización (como OAuth 2.0). Asegúrese de que estos tokens
caduquen con la mayor frecuencia posible.
2.2 En caso de que sea necesario almacenar contraseñas en el dispositivo, aproveche los mecanismos de
cifrado y almacenamiento de claves proporcionados por el sistema operativo móvil para almacenar de
forma segura contraseñas, equivalentes de contraseña y tokens de autorización. Nunca almacene
contraseñas en texto claro. No almacene contraseñas o ID de sesión a largo plazo sin hash o cifrado
adecuados.
2.3 Algunos dispositivos y complementos permiten a los desarrolladores utilizar un elemento seguro, por
ejemplo (5) (6), a veces a través de un módulo de tarjeta SD, es probable que aumente el número de
dispositivos que ofrecen esta funcionalidad. Los desarrolladores deben hacer uso de tales capacidades
para almacenar claves, credenciales y otros datos confidenciales. El uso de tales elementos seguros brinda
un mayor nivel de seguridad con la tarjeta SD estándar encriptada certificada en FIPS 140-2 Nivel 3. Sin
embargo, no se recomienda el uso de tarjetas SD como segundo factor de autenticación, ya que se vuelve
una parte pseudo inseparable del dispositivo una vez insertado y asegurado.
2.4 Proporcione la capacidad para que el usuario móvil cambie las contraseñas en el dispositivo.
2.5 Las contraseñas y credenciales solo deben incluirse como parte de copias de seguridad regulares en
forma cifrada o hash.
2.6 Los teléfonos inteligentes ofrecen la posibilidad de utilizar contraseñas visuales que permiten a los
usuarios memorizar contraseñas con mayor entropía. Sin embargo, estos solo deberían usarse si se puede
garantizar una entropía suficiente. (7)
6-6-2018
2.7 Las contraseñas visuales basadas en deslizamiento son vulnerables a los ataques de manchas (usando
depósitos de grasa en la pantalla táctil para adivinar la contraseña). Se deben introducir medidas tales
como permitir patrones repetidos para frustrar los ataques de borrones. (8)
2.8 Compruebe la entropía de todas las contraseñas, incluidas las visuales (ver 4.1 a continuación).
2.9 Asegúrese de que las contraseñas y las claves no estén visibles en la caché o los registros.
2.10 No almacene contraseñas ni secretos en el binario de la aplicación. No utilice un secreto compartido
genérico para la integración con el servidor (como la contraseña incrustada en el código). Los archivos
binarios de aplicaciones móviles se pueden descargar fácilmente y realizar ingeniería inversa.
3. Asegurar que los datos confidenciales estén protegidos en tránsito

Riesgos: ataques de suplantación de redes, vigilancia. La mayoría de los teléfonos inteligentes son
capaces de utilizar múltiples mecanismos de red que incluyen Wi-Fi, red de proveedores (3G, GSM, CDMA
y otros), Bluetooth, etc. Se pueden interceptar datos confidenciales que pasan por canales inseguros. (9)
(10)
3.1 Suponga que la capa de red del proveedor no es segura. Los ataques modernos de la capa de red
pueden descifrar el cifrado de la red del proveedor, y no hay garantía de que la red Wi-Fi esté debidamente
encriptada.
3.2 Las aplicaciones deben exigir el uso de un canal seguro de extremo a extremo (como SSL / TLS) al
enviar información sensible a través del cable o el aire (por ejemplo, utilizando Strict Transport Security -
STS (11)). Esto incluye el paso de credenciales de usuario, u otros equivalentes de autenticación. Esto
proporciona confidencialidad y protección de integridad.
3.3 Utilice algoritmos de cifrado fuertes y conocidos (por ejemplo, AES) y longitudes de clave apropiadas
(consulte las recomendaciones actuales para el algoritmo que utiliza, por ejemplo, (12) página 53).
3.4 Usar certificados firmados por proveedores de CA confiables. Tenga mucho cuidado al permitir
certificados autofirmados. No desactive o ignore la validación de la cadena SSL.
3.5 Para datos confidenciales, para reducir el riesgo de ataques intermedios (como proxy SSL, franja SSL),
una conexión segura solo debe establecerse después de verificar la identidad del punto final remoto
(servidor). Esto se puede lograr asegurando que SSL solo se establezca con puntos finales que tengan los
certificados confiables en la cadena de claves.
3.6 La interfaz de usuario debe facilitar al usuario la búsqueda de un certificado válido.
3.7 SMS, MMS o notificaciones no deben usarse para enviar datos confidenciales hacia o desde puntos
finales móviles.
Referencia: vulnerabilidad de Google de credenciales de cuenta de inicio de sesión de cliente en wifi
desprotegido - [1]
4. Implementar correctamente la autenticación de usuario, la autorización y la gestión de sesión

Riesgos: las personas no autorizadas pueden obtener acceso a datos o sistemas confidenciales eludiendo
los sistemas de autenticación (inicios de sesión) o reutilizando tokens o cookies válidos. (13)
6-6-2018
4.1 Requerir autenticación de usuario de fuerza apropiada a la aplicación. Puede ser útil proporcionar
comentarios sobre la fortaleza de la contraseña cuando se ingresa por primera vez. La solidez del
mecanismo de autenticación utilizado depende de la sensibilidad de los datos procesados por la aplicación
y su acceso a recursos valiosos (por ejemplo, costos de dinero).
4.2 Es importante asegurarse de que la administración de la sesión se maneje correctamente después de
la autenticación inicial, utilizando los protocolos de seguridad apropiados. Por ejemplo, se requieren
credenciales de autenticación o tokens para pasar con cualquier solicitud posterior (especialmente aquellas
que otorgan acceso o modificación privilegiada).
4.3 Usa identificadores de sesión impredecibles con alta entropía. Tenga en cuenta que los generadores de
números aleatorios generalmente producen resultados aleatorios pero predecibles para una semilla
determinada (es decir, se produce la misma secuencia de números aleatorios para cada semilla). Por lo
tanto, es importante proporcionar una semilla impredecible para el generador de números aleatorios. El
método estándar para usar la fecha y la hora no es seguro. Se puede mejorar, por ejemplo, usando una
combinación de fecha y hora, el sensor de temperatura del teléfono y los campos magnéticos actuales x, y
y z. Al usar y combinar estos valores, se deben elegir algoritmos bien probados que maximicen la entropía
(p. Ej., La aplicación repetida de SHA1 puede usarse para combinar variables aleatorias mientras se
mantiene la máxima entropía, suponiendo una longitud de semilla máxima constante).
4.4 Usar contexto para agregar seguridad a la autenticación, por ejemplo, ubicación de IP, etc.
4.5 Siempre que sea posible, considere utilizar factores de autenticación adicionales para las aplicaciones
que brindan acceso a datos o interfaces confidenciales cuando sea posible, por ejemplo, voz, huella dactilar
(si está disponible), quién sabe, comportamiento, etc.
4.6 Usar autenticación que vincule a la identidad del usuario final (en lugar de la identidad del dispositivo).
5. Mantenga seguras las API de backend (servicios) y la plataforma (servidor)
Riesgos: ataques a sistemas de back-end y pérdida de datos a través del almacenamiento en la nube. La
mayoría de las aplicaciones móviles interactúan con las API de fondo mediante REST / Servicios web o
protocolos propietarios. La implementación insegura de API o servicios de back-end, y no mantener la
plataforma back-end reforzada / parcheada permitirá a los atacantes poner en peligro los datos en el
dispositivo móvil cuando se transfieren al backend, o atacar el backend a través de la aplicación móvil. (14)
5.1 Realice una verificación específica de su código para datos confidenciales transferidos
involuntariamente, cualquier información transferida entre el dispositivo móvil y el servidor web y otras
interfaces externas (por ejemplo, la ubicación u otra información incluida en los metadatos de archivos).
5.2 Todos los servicios de back-end (servicios web / REST) para aplicaciones móviles deberían someterse
a pruebas de vulnerabilidades periódicamente, por ejemplo, utilizando herramientas analíticas de códigos
estáticos y herramientas de fuzzing para probar y encontrar fallas de seguridad.
5.3 Asegúrese de que la plataforma de backend (servidor) se esté ejecutando con una configuración
reforzada con los últimos parches de seguridad aplicados al sistema operativo, el servidor web y otros
componentes de la aplicación.
5.4 Asegurar que los registros adecuados se retengan en el back-end para detectar y responder a
incidentes y realizar análisis forenses (dentro de los límites de la ley de protección de datos).
5.5 Emplear limitación de velocidad y aceleración por usuario / IP (si la identificación del usuario está
disponible) para reducir el riesgo de ataque DDoS.
6-6-2018
5.6 Prueba de vulnerabilidades de DoS donde el servidor puede verse abrumado por ciertas llamadas a la
aplicación que consumen muchos recursos.
5.7 Los servicios web, REST y API pueden tener vulnerabilidades similares a las aplicaciones web:
Realizar pruebas de casos de abuso, además de las pruebas de casos de uso
Realice pruebas del servicio web back-end, REST o API para determinar las vulnerabilidades.
6. Integración segura de datos con servicios y aplicaciones de terceros

Riesgos: fuga de datos. Los usuarios pueden instalar aplicaciones que pueden ser maliciosas y pueden
transmitir datos personales (u otros datos almacenados confidenciales) con fines maliciosos.
6.1 Ver la seguridad / autenticidad de cualquier código / biblioteca de terceros utilizado en su aplicación
móvil (por ejemplo, asegurándose de que provienen de una fuente confiable, con soporte de
mantenimiento, sin troyanos de backend)
6.2 Haga un seguimiento de todos los marcos / API de terceros utilizados en la aplicación móvil para los
parches de seguridad. Se debe realizar una actualización de seguridad correspondiente para las
aplicaciones móviles que utilizan estas API / frameworks de terceros.
6.3 Preste especial atención a la validación de todos los datos recibidos y enviados a aplicaciones de
terceros no confiables (por ejemplo, software de red publicitaria) antes de procesar dentro de la aplicación.
7. Preste atención específica a la recopilación y almacenamiento de consentimiento para la
recopilación y el uso de los datos del usuario
Riesgos: divulgación involuntaria de información personal o privada, procesamiento de datos ilegal. En la
Unión Europea, es obligatorio obtener el consentimiento del usuario para la recopilación de información de
identificación personal (PII). (15) (16)
7.1 Crear una política de privacidad que cubra el uso de los datos personales y ponerla a disposición del
usuario, especialmente cuando se toman decisiones de consentimiento.
7.2 El consentimiento se puede recopilar de tres maneras principales:
En el momento de la instalación
En tiempo de ejecución cuando se envían datos
A través de mecanismos de "exclusión" donde se implementa una configuración predeterminada y el
usuario tiene que desactivarla.
7.3 Verifique si su aplicación está recopilando PII, puede no ser siempre obvio, por ejemplo, ¿utiliza
identificadores únicos persistentes vinculados a almacenes de datos centrales que contienen información
personal?
7.4 Mecanismos de comunicación de auditoría para verificar fugas involuntarias (por ejemplo, metadatos de
imágenes).
6-6-2018
7.5 Mantener un registro de consentimiento para la transferencia de PII. Este registro debe estar disponible
para el usuario (considere también el valor de mantener registros del lado del servidor adjuntos a los datos
del usuario almacenados). Tales registros en sí mismos deberían minimizar la cantidad de datos
personales que almacenan (p. Ej., Usar hash).
7.6 Compruebe si su mecanismo de recolección de consentimiento se superpone o entra en conflicto (por
ejemplo, en las prácticas de manejo de datos indicadas) con cualquier otra colección de consentimiento
dentro de la misma pila (por ejemplo, APP-native + HTML de webkit) y resuelva cualquier conflicto.
8. Implementar controles para evitar el acceso no autorizado a recursos pagados (billetera, SMS,
llamadas telefónicas, etc.)
Riesgos: las aplicaciones para teléfonos inteligentes brindan acceso programático (automático) a llamadas
telefónicas de tarifa premium, SMS, datos de itinerancia, pagos NFC, etc. con acceso privilegiado a tales
API, se debe tener especial cuidado para evitar abusos, teniendo en cuenta el impacto financiero de las
vulnerabilidades que dan acceso a los atacantes a los recursos financieros del usuario.
8.1 Mantener registros de acceso a los recursos pagados en un formato no repudiable (por ejemplo, un
recibo firmado enviado a un servidor confiable - con el consentimiento del usuario) y ponerlos a disposición
del usuario final para su supervisión. Los registros deben estar protegidos del acceso no autorizado.
8.2 Comprobar patrones de uso anómalos en el uso de recursos pagados y desencadenar la
reautorización. Por ejemplo, cuando ocurre un cambio significativo en la ubicación, cambios en el idioma
del usuario, etc.
8.3 Considere el uso de un modelo de lista blanca por defecto para el direccionamiento de recursos
pagados, por ejemplo, la libreta de direcciones solo a menos que esté específicamente autorizado para
llamadas telefónicas.
8.4 Autenticar todas las llamadas API a los recursos pagados (por ejemplo, utilizando un certificado de
desarrollador de la aplicación).
8.5 Asegurarse de que las devoluciones de llamada API de billetera no pasen la información de cuenta /
precios / facturación / artículo sin formato.
8.6 Advertir al usuario y obtener el consentimiento para cualquier implicancia de costos para el
comportamiento de la aplicación.
8.7 Implemente las mejores prácticas, como la latencia rápida (una especificación 3GPP), el
almacenamiento en caché, etc. para minimizar la carga de señalización en las estaciones base.
9. Garantizar la distribución / provisión segura de aplicaciones móviles
Riesgos: El uso de prácticas seguras de distribución es importante para mitigar todos los riesgos descritos
en los 10 principales riesgos de OWASP Mobile y en los 10 principales riesgos de ENISA.
9.1 Las aplicaciones deben diseñarse y aprovisionarse para permitir actualizaciones de parches de
seguridad, teniendo en cuenta los requisitos de aprobación por parte de las tiendas de aplicaciones y la
demora adicional que esto pueda implicar.
6-6-2018
9.2 La mayoría de las tiendas de aplicaciones monitorean las aplicaciones en busca de códigos inseguros y
pueden eliminar aplicaciones de forma remota con poca anticipación en caso de un incidente. La
distribución de aplicaciones a través de tiendas de aplicaciones oficiales, por lo tanto, proporciona una red
de seguridad en caso de serias vulnerabilidades en su aplicación.
9.3 Proporcione canales de retroalimentación para que los usuarios informen sobre problemas de
seguridad con las aplicaciones, por ejemplo, una dirección de correo electrónico de seguridad @.
10. Compruebe cuidadosamente cualquier interpretación en tiempo de ejecución del código para
errores
Riesgos: la interpretación en tiempo de ejecución del código puede dar la oportunidad a las partes que no
son de confianza de proporcionar una entrada no verificada que se interpreta como código. Por ejemplo,
niveles extra en un juego, scripts, encabezados de SMS interpretados. Esto brinda la oportunidad al
malware de eludir los controles de jardín amurallados proporcionados por las tiendas de aplicaciones.
Puede conducir a ataques de inyección que conducen a fuga de datos, vigilancia, spyware y software de
marcación.
Tenga en cuenta que no siempre es obvio que su código contiene un intérprete. Busque cualquier
capacidad accesible a través de datos de entrada del usuario y el uso de API de terceros que pueden
interpretar la entrada del usuario, por ejemplo, intérpretes de JavaScript.
10.1 Minimice la interpretación del tiempo de ejecución y las capacidades ofrecidas a los intérpretes en
tiempo de ejecución: ejecute intérpretes con niveles mínimos de privilegio.
10.2 Defina la sintaxis de escape completa según corresponda.
10.3 Intérpretes de prueba de Fuzz.
10.4 Intérpretes de Sandbox.
Conclusión
Los móviles han ocupado una parte muy importante en nuestra sociedad. Ya hace mucho tiempo
que se superó el tráfico de red por móvil que por ordenador. Como desarrolladores, tenemos la
obligación de intentar hacer el acceso desde estos dispositivos lo más seguro posible.
BIBLIOFRAFIA
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

Documento de Owasp

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Documento de Owasp

Transféré par

Droits d'auteur :

Formats disponibles

HERRAMIENTA OWASP MOBILE

OWASP Mobile Security Project

OWASP Mobile Security Project

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Los 10 principales riesgos móviles - Lista final 2016

o M1 - Uso inadecuado de la plataforma. Esta categoría cubre el uso indebido de una

Agentes de Vectores de Impactos Impactos

Esta categoría Los vectores de Para explotar esta El impacto El impacto

¿Soy vulnerable al 'uso inadecuado de la plataforma'?

¿Como evito el uso inadecuado de la plataforma?

M2 - Almacenamiento de datos inseguros. Esta nueva categoría es una combinación de M2 +

Agentes de Vectores de Impactos Impactos

¿Soy vulnerable al "almacenamiento de datos inseguros"?

 Bases de datos SQL;

 La forma en que el sistema operativo almacena datos, imágenes, pulsaciones de teclas,

 Caché de URL (tanto solicitud como respuesta);

 Copiar / Pegar el almacenamiento en memoria intermedia del búfer

o M3 - Comunicación insegura. Esto incluye mala comunicación, versiones incorrectas de SSL,

Agentes de Vectores de Impactos Impactos

¿Cómo evito la "comunicación insegura"?

 Suponga que la capa de red no es segura y es susceptible de escuchas.

 Asegúrese de que los certificados sean válidos y fallen.

 No identificar al usuario en absoluto cuando eso debería ser requerido

Agentes de Vectores de Impactos

disponibles o solicitudes bastante frecuente establecer la identidad  Robo de

 Si la aplicación móvil almacena contraseñas o secretos compartidos localmente en el

¿Cómo evito la 'Autenticación insegura'?

 Autenticar a un usuario localmente puede conducir a vulnerabilidades de derivación del lado

 La funcionalidad de autenticación persistente (Remember Me) implementada en aplicaciones

o M5 - Criptografía insuficiente. El código aplica criptografía a un activo de información

Agentes de Vectores de Impactos Impactos

los datos  Robo de

Confianza en los procesos de encriptación de códigos incorporados

 Hacer que las llaves estén disponibles para el atacante;

 Evite el almacenamiento de datos confidenciales en un dispositivo móvil cuando sea posible.

que las verificaciones de autorización siempre deben seguir inmediatamente a la autenticación de

 Presencia de vulnerabilidades inseguras de referencia directa de objeto (IDOR) : si ve

 Puntos finales ocultos : por lo general, los desarrolladores no realizan comprobaciones de

 Funciones de usuario o transmisiones de permisos : si la aplicación móvil está

Agentes de Vectores de Impactos Impactos

 Mantener patrones de codificación consistentes en los que todos en la organización estén de

o M8 – Manipulacion del Código .Esta categoría cubre el parche binario, la modificación de

para obtener ganancias

¿Soy vulnerable al 'Código Manipulación'?

 Compruebe si el archivo /etc/security/otacerts.zip existe

 Intente ejecutar el comando su y verifique la identificación del usuario actual, si devuelve 0,

Agentes de Vectores de Impactos

como IDA Pro, ataque" de este documento  Obtenga la

 Entender claramente el contenido de la tabla de cadenas de un binario

Aunque la mayoría de las aplicaciones son susceptibles de ingeniería inversa, es importante

¿Cómo evito la "ingeniería inversa"?

Agentes de Impactos Impactos

1. Examine la configuración de la aplicación para descubrir cualquier interruptor oculto;

Los 10 mejores controles móviles

1. Identificar y proteger datos confidenciales en el dispositivo móvil

2. Manejar las credenciales de contraseña de forma segura en el dispositivo

3. Asegurar que los datos confidenciales estén protegidos en tránsito

4. Implementar correctamente la autenticación de usuario, la autorización y la gestión de sesión

6. Integración segura de datos con servicios y aplicaciones de terceros

Vous aimerez peut-être aussi