DESARROLLO SEGURO DE APLICACIONES MÓVILES APLICANDO ...

Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.

1

DESARROLLO SEGURO DE APLICACIONES

MÓVILES APLICANDO PRINCIPIOS DE LA

NORMA ISO 27001 López Vargas, Johann Harry.

[email protected]

Universidad Piloto de Colombia

Resumen—El propósito de este artículo, es

identificar las características que son necesarias

para el desarrollo seguro de aplicaciones móviles,

brindando un enfoque que permita alinearse con los

estándares de la norma internacional ISO 27001

versión 2013; aplicando conceptos generales que

empresas y organizaciones reconocidas, a nivel

mundial han desarrollado a lo largo de los años y

facilitaran implementar los procedimientos

necesarios para alcanzar este objetivo.

Abstract— The purpose of this article; is to

identify the features, that are necessary for the

secure development of mobile applications,

providing an approach that allows alignment with

the standards of the international standard ISO

27001 version 2013. Applying general concepts,

that companies and organizations recognized

worldwide have developed over the years and will

facilitate the implementation of the necessary

procedures to achieve this objective.

Índice de Términos—aplicaciones seguras,

desarrollo de aplicaciones, implementación de

seguridad, principios de la norma ISO 27001,

ingeniería de software.

I. INTRODUCCIÓN

Actualmente el mundo ha alcanzado un nivel de

interconexión jamás imaginado. Según un estudio

realizado por el Fondo Monetario Internacional,

“La demanda de equipos móviles se ha

incrementado a una cifra casi astronómica y su

tendencia indica, un crecimiento de adquisición

mayor con el paso de los años” (Ver Fig. 1), el

crecimiento del mercado ha generado que las

personas hoy en día puedan acceder más fácilmente

a tecnologías, que en años anteriores no eran tan

comunes; motivo por el cual, no existe actualmente

una preparación adecuada que pueda afrontar los

retos de seguridad que esto conlleva.

El crecimiento en la demanda ha generado una

cantidad descomunal de aplicaciones para todo tipo

Fig. 1. Crecimiento en la demanda de Smartphones en los últimos

años, Obtenida de https://www.econmatters.com/2018/02/is-

smartphones-demand-peaking.html

de situación, estas son indiscriminadamente

instaladas por los diferentes usuarios y son usadas,

en diferentes contextos en el día a día; ya sea por

temas laborales, el incremento de la productividad,

acceso a contenido educativo e incluso, consumo de

ocio.

El crecimiento descomunal de los dispositivos ha

convertido el mercado móvil no solo en un objetivo

comercial, también ha llamado la atención de los

criminales informáticos; es por eso, por lo que

existe una necesidad de producir aplicaciones de

manera rápida y tal vez, sin la correcta

implementación de las consideraciones necesarias

en su desarrollo, que permitan entregar al cliente

final una herramienta acorde a unos mínimos


2

estándares de seguridad y calidad. El ramillete de

opciones está servido en la mesa. En las diferentes

tiendas de aplicaciones podemos encontrar

software, tanto para la integración como para

ofrecer nuevas experiencias a los consumidores

finales, convirtiéndose en algo imprescindible y

quien no cuente con este recurso, pierde nivel

competitivo en su nicho de interacción.

Pero, ¿Qué conlleva este crecimiento? ¿Qué

impacto tiene en las diferentes áreas tecnológicas de

las empresas? ¿Hemos evaluado la necesidad de

implementar medidas para mitigar los riesgos que

generan este tipo de dispositivos en una

organización?, aún la respuesta es incierta y de

difícil evaluación; los llamados “smartphone”,

dando un vistazo desde un punto de vista técnico,

son equipos que ofrecen el mismo servicio que un

computador de escritorio, pero con la ventaja de la

portabilidad, es por eso que su uso se ha masificado

y de igual forma, se ha multiplicado el riesgo de

seguridad.

Teniendo como base el anterior análisis,

podemos identificar claramente que el desarrollo

móvil, se ha incrementado en los últimos años y

esto conlleva, al reto de suplir y monetizar este tipo

de productos. Para intentar cumplir y satisfacer las

exigencias de sus clientes, esto nos conduce a

realizar el siguiente cuestionamiento: ¿Se toman las

medidas necesarias para que con cada desarrollo se

cumplan con los requisitos mínimos de seguridad

que preserven la disponibilidad, integridad y

confidencialidad de la información?,

lastimosamente la respuesta es NO; vemos con

cierta preocupación que la necesidad de cumplir con

estos estándares, no es algo que esté dentro de las

prioridades de los proveedores de este servicio, ni

tampoco existe una conciencia de crear un

presupuesto que permita cumplir con este alcance.

La organización sin ánimo de lucro OWASP, que

se encarga de apoyar los esfuerzos que encaminen a

las instituciones, empresas y mercado en general

para concebir, desarrollar, adquirir, operar y

mantener aplicaciones en las que se pueda confiar

[1], plantea un Top 10 de vulnerabilidades, las

cuales afectan a los diferentes dispositivos móviles

a nivel mundial; este referente podría ser un punto

de partida para identificar la necesidad de establecer

una serie de prácticas en las diferentes

organizaciones, para brindar un producto con

óptimos niveles de seguridad y que cumplan, a

satisfacción con los requerimientos de las empresas

y sus clientes, implementando unas mejores

prácticas que minimicen las afectaciones, que

podrían presentarse por el uso indebido de estas

tecnologías, realizando los análisis de riesgos

correspondientes y planteando un modelo para el

control de amenazas, como punto de partida para el

inicio de cualquier construcción de un software; y

puedan sentar las bases de una correcta

implementación, en donde el enfoque sea un

procedimiento de seguridad, que por medio de las

buenas prácticas permita generar un valor agregado,

en donde se apliquen unos correctos controles que

favorezcan, el desarrollo de productos con un

máximo nivel de calidad y seguridad.

II. A QUÉ NOS ENFRENTAMOS

Fig. 2. Top 1 de Vulnerabilidades OWASP para dispositivos móviles,

obtenida de https://www.owasp.org/index.php/OWASP_ Mobile_

Security_Project#tab=Top_10_Mobile_Risks

En la imagen anterior, (Ver Fig. 2) la

organización OWASP presenta un top 10 de

vulnerabilidades, que se pueden presentar en los

dispositivos móviles [2]; estas vulnerabilidades en

los sistemas, no identifican la totalidad del

conjunto, que podemos encontrar en los diferentes

ámbitos de desarrollo y producción, pero sí nos

brindan un norte para poder empezar a evaluar, qué

nivel de seguridad ha sido implementado en cada

uno de los procesos de construcción y despliegue,

para el usuario final.

Las vulnerabilidades que ofrece este top OWASP,

son las recopilaciones de diferentes colaboradores a

nivel mundial, que permitieron identificar los

https://www.owasp.org/index.php/


3

mayores riesgos de los sistemas móviles. A

continuación, daremos una visión general de los

principales:

A. M1-Controles Débiles de lado servidor

La dificultad para desarrollar una implementación

mínima de seguridad, que permita identificar

vulnerabilidades en los servicios Apis de terceros,

como se describe en OWASP, es todo lo que pueda

salir mal que no tiene lugar en el teléfono

(CLOUD).

B. M2- Almacenamiento de datos inseguros:

Esta vulnerabilidad se presenta cuando los

equipos de desarrollo, confían que los usuarios u

otro software; no tendrá acceso a datos sensibles de

la aplicación.

C. M3- Debilidad en la protección de la capa de

transporte

Las aplicaciones a menudo no protegen el tráfico

en la red y exponen información crítica del usuario.

D. M4- Fuga involuntaria de datos

Esta pérdida se produce cuando el desarrollador,

almacena información sensible en secciones del

sistema operativo como: cache, cookies,

portapapeles y puede, ser fácilmente accedida por

terceros, exponiendo la información crítica del

usuario.

E. M5- Pobres mecanismos de autenticación y

autorización:

Los mecanismos pobres o inexistentes, para la

autenticación de una aplicación, permiten el ingreso

de modo anónimo en la aplicación.

F. M6- Uso Inseguro de Criptografía

El uso de algoritmos de cifrado débiles o su mala

implementación, permitirían a un adversario, tener

acceso a la información crítica del usuario que usa

el sistema.

G. M7- Inyección de lado del Cliente

Permite ejecutar código malicioso directamente

en el dispositivo móvil, a través de las mismas

aplicaciones instaladas. La estructuración de las

fuentes de entrada no permite una validación

correcta y son susceptibles a ingreso de datos

incorrectos, que pueden afectar el sistema.

H. M8- Decisiones de seguridad a través de

entradas no confiables.

La aplicación puede aceptar datos de cualquier

fuente IPC (inglés Inter Process Comunication), la

cual es una función básica de los sistemas

operativos, que permite que los procesos puedan

comunicarse entre sí, compartiendo espacios de

memoria [3], sin que exista un filtro para acceder a

estas comunicaciones.

I. M9- Manejo incorrecto de sesión

Cuando se realiza una autenticación entre el

cliente y el servidor, se comparte un TOKEN de

sesión, el cual es administrado para realizar las

diferentes transacciones mientras dure la sesión; un

manejo o exposición no adecuado permite que un

adversario, pueda acceder a esta información y

pueda suplantar al cliente.

J. M10 – Falta de protecciones binarias

La aplicación no tiene mecanismos que permitan

protegerla contra la ingeniería inversa; el análisis de

flujo de control, la modificación de la capa de

control HTML o la modificación de un ejecutable

binario, que evite pasar por un control de seguridad.

El común de las vulnerabilidades expuestas por

esta organización indica que, los elementos que

convergen puedan materializarse en un ataque o una

exposición de datos críticos, hasta un nivel de:

infraestructura, transporte y desarrollo. Esta

convergencia de factores, es el campo de acción, al

que tiende a estar expuesto cualquier software, que

se encuentre abierto a un público general u objetivo.

Para evaluar qué tanto está expuesta, una

determinada aplicación a estos factores, es

necesario identificar en qué grado de madurez se

tiene la implementación de los procesos de

seguridad y cómo poder alinearnos a los objetivos

estratégicos de la organización; siendo necesario

establecer una estrategia que nos permita dar

seguimiento, a las actividades de control de nuestros

elementos de desarrollo.

III. CONCIENCIACIÓN

La Real Academia de la Lengua RAE [4] describe

concienciar como: “Hacer que alguien sea

consciente de algo”; esta definición es importante

tenerla en cuenta, ya que es el punto de partida para

iniciar cualquier proceso, que busque implementar

herramientas para un desarrollo seguro. Las

organizaciones han adoptado tecnologías

importantes en los últimos años y es común ver,

como las empresas han sistematizado una enorme


4

cantidad de sus procesos, haciendo grandes

inversiones en la compra de nuevos recursos, que le

permitan generar un recorte de gastos y una mayor

eficiencia de estos.

Esta tecnificación ha ayudado a las empresas a

tener un mejor control sobre sus recursos, lo cual

actualmente, se ha convertido en uno de los grandes

puntos débiles, debido a la falta de conciencia por

parte de la alta gerencia y el personal en general.

La norma internacional ISO 27001[4] nos indica en

su numeral 7.3, la necesidad de crear una conciencia

de seguridad en la organización, siendo un factor

decisivo para establecer procedimientos, que hagan

más seguras las unidades de trabajo; los equipos de

desarrollo, actualmente deben ser concientizados

sobre los riesgos a los que se exponen en su trabajo,

ya que, esto junto a la falta de controles afecta a la

organización y a las personas, que son destinatarios

del producto final.

El primer paso por dar en la organización es

reconocer que hay riesgos y vulnerabilidades

latentes, que pueden afectar sus productos, su

imagen y su reputación en el mercado; riesgos que

deben ser transmitidos y analizados, desde el punto

de vista económico, para que se pueda evaluar el

posible impacto en caso de presentarse. Por tal

motivo, una vez que la organización entienda que se

encuentra expuesta, debe evaluar el riesgo, e

identificar los factores que puede converger en su

contra.

IV. ANÁLISIS DE RIESGOS

El análisis de riesgos es el estudio de las posibles

causas de las diferentes amenazas. La frecuencia

con la que pueda presentarse y como pueden afectar

una organización, son probables eventos que

podrían materializarse y atentar negativamente

contra los activos. En el desarrollo de software,

estos riesgos son intangibles, por lo que hace más

difícil su identificación y el impacto, es más

imperceptible; es por tal motivo, que su

identificación debe ser objeto de estudio en cada

inicio de proyecto y no se debe desconocer, la

necesidad de su implementación.

La seguridad de un producto de software está

determinada por una serie de factores, que

convergen desde su creación hasta su obsolescencia;

los protocolos de comunicación, la arquitectura del

sistema y la legislación, son una serie de elementos

para tener en cuenta, ya que pueden blindar el

desarrollo, prevenir y generar un protocolo de

acción, en caso de que se produzca un incidente que

atente contra la seguridad de la información. Pero,

¿cómo determinamos que posibles amenazas

pueden ser materializadas y afectar nuestro

desarrollo?, el análisis de riesgo es la respuesta que

nos permite contemplar un panorama y unos

objetivos más claros, que en consecuencia permite

trabajar en la metodología de aplicación, que puede

tener como punto de seguimiento las normas o

estándares existentes, como lo son las normas ISO

27005 e ISO 31000, u otras metodologías

comúnmente aceptadas, que ofrecen los conceptos

necesarios, para una correcta evaluación del riesgo

y su adecuación en el contexto del negocio y sus

interrelaciones con otras áreas. Las siguientes son

actividades y acciones, para tener en cuenta en un

análisis de riesgos [5]:

1) Definir el alcance, estableciendo las necesidades

coyunturales del proyecto.

2) Identificación de los activos, que participaran en

el proceso: infraestructura, software, talento

humano, etc.

3) Identificación de los requisitos legales y de

negocio, que son relevantes, para brindar soporte a

los activos y son propios de cada país, donde se

desarrolle el producto.

4) Identificación de posibles amenazas.

5) Identificar vulnerabilidades.

6) Evaluación del riesgo, que dependerá

directamente de las necesidades y posible impacto

de cada organización.

7) Documentar el análisis.

La identificación del riesgo es un factor

indispensable, para iniciar el proceso de

implementación de seguridad, es una condición

previa que permite dimensionar el alcance y la

necesidad del proyecto, estos valores nos permiten

cuantificar y dar un indicador, para la toma de

decisiones.

Cada vez que se realice un proyecto, es necesario

realizar una evaluación inicial y volver a retornar


5

este análisis en periodos de tiempo prudentes, con el

fin de poder identificar nuevos riesgos adyacentes y

revisar cómo se han venido manejando los que se

contemplaron en la etapa inicial. La calificación que

se le asigna a cada riesgo, está determinada en

función de la obtención del valor del índice de

probabilidad, de ser una amenaza x la magnitud del

daño y el resultado en el impacto en el activo que

está afectando, cada compañía elabora esto de

manera arbitraria; debido a que sus activos no están

en la misma escala de valor de otras compañías.

Fig. 3. Ejemplo de valoración del riesgo, obtenida de:

https://protejete.wordpress.com/gdr_principal/analisis_riesgo/

La valoración está comprendida en una escala

dada, de acuerdo con los criterios de evaluación de

cada organización, en la medida en que se tengan

identificados los riesgos (Ver Fig. 3) se podrán

establecer las medidas preventivas o correctivas

para dar tratamiento.

Al realizar el análisis de riesgo, la participación

de los diferentes procesos que interactúan en un

proyecto de desarrollo, son indispensables, como

resultado, los aportes que se realicen harán

extensibles esta evaluación y determinará con

mayor comprensión, los elementos que intervienen

en el proceso.

Algunas empresas dentro de sus diferentes áreas

de seguridad, ya cuentan con un plan para el control

de riesgos informáticos, en este se contempla su

evaluación y su tratamiento; se debe tener claro que

éste no necesariamente es aplicable para todos los

casos, es por eso, por lo que se recomienda siempre,

evaluar su aplicación específica, cada vez que

empiece un nuevo proyecto, para el desarrollo de un

producto o servicio en la compañía u organización.

V. MODELADO DE AMENAZAS

Con el análisis de riesgos podemos identificar las

vulnerabilidades inherentes, que se presentan al

momento de desarrollar un proyecto, el modelo de

amenazas está enfocado al desarrollo de

aplicaciones, su objetivo principal es ponernos en

los zapatos del defensor y atacante, como nos lo

indica OWASP[6]: “El modelado de amenazas es

una representación estructurada de toda la

información que afecta la seguridad de una

aplicación, en esencia, es una vista de la aplicación

y su entorno a través de las gafas de la seguridad”,

es decir, es un análisis más enfocado a la parte

técnica, sin que se llegue a revisar el código, pero sí

complementando el proceso de revisión de

seguridad. Según Microsoft [7], utilizar esta

estrategia trae unas ventajas que podríamos

enumerar de la siguiente manera:

1) Facilidad de comprensión de la aplicación.

2) Ayuda a detectar errores.

3) Ayuda a los miembros del equipo a entender la

aplicación con mayor profundidad.

4) Contiene información importante para que otros

equipos trabajen con la aplicación.

5) Resulta de utilidad para los evaluadores.

El modelado de amenazas permite tomar

decisiones, dando prioridad a los riesgos de

seguridad en la aplicación y tiene las siguientes

características:

A. Objetivos del Modelado de Amenazas

El objetivo es determinar los riesgos de

seguridad, que pueden aparecer en un producto de

software, aplicación o entorno, así como la forma en

cómo se materializan los ataques, identificando las

amenazas y que tipo de mitigación requieren.

El modelado de aplicaciones no es un análisis de

riesgos convencional que se aplica a un proyecto

general específico, es una herramienta que nos

ayuda a mejorar la arquitectura, diseño y

codificación de manera cíclica, enfocándonos en

adquirir características seguras en el desarrollo del


6

software.

B. Características del modelo de Amenazas

Cuando realizamos un modelado de amenazas

este debe ser capaz de:

1) Identificar amenazas inherentes al uso o

naturaleza de la aplicación.

2) Identificar Vulnerabilidades que podrían ser

explotadas, por un atacante o por mal uso del

recurso.

3) Obtener información de las contramedidas

necesarias, para mitigar el riesgo resultante de los

hallazgos encontrados o posibles escenarios.

4) Socializar el resultado del análisis a las

diferentes áreas y a los superiores encargados.

5) Poder establecer una estrategia, para minimizar

las brechas de seguridad encontradas en el análisis.

C. Proceso de Modelado de Aplicaciones

Según el proceso presentado por OWASP [8],

este se divide en tres pasos de alto nivel:

1) Descomposición de la Aplicación:

Comprender la lógica de la aplicación y su

interacción con los diferentes componentes, tanto

internos como externos; tener diseñados casos de

uso para determinar su alcance; generar diagramas

de flujo que visualmente proporcionen un modelo

detallado.

2) Determinar y Clasificar las amenazas:

Se debe categorizar las amenazas para

comprender la situación de parte del atacante, como

la perspectiva de defensiva; los flujos de procesos

identificados en la descomposición de la aplicación,

ayudan a darnos una vista de posibles objetivos,

como fuentes de datos y la interacción del usuario.

3) Determinar las contramedidas y la mitigación:

Las amenazas podrían materializarse cuando se

explota una vulnerabilidad, pero podrían mitigarse

con una contramedida; estas pueden mapearse en

una lista y se pueden clasificar de mayor a menor

según sea su impacto.

El proceso debe documentarse a medida que va

realizándose, con el fin de poder dar seguimiento y

brindar asistencia a las personas que intervengan

posteriormente, explicando los conceptos y las

medidas tomadas para mitigarlos. El análisis de

proyectos anteriores puede ser un punto de partida,

para identificar amenazas generales y evitar volver

analizarlas.

VI. PASOS PARA REALIZAR EL MODELO

DE AMENAZAS

El proceso de modelado de aplicaciones según las

recomendaciones de Microsoft [9], debe tomar en

cuenta los siguientes pasos para poder tener éxito en

su realización:

A. Recopilar información básica:

El claro entendimiento del funcionamiento de una

aplicación, es fundamental para poder determinar

las características y necesidades del sistema; esta

recopilación de datos nos permitirá, identificar el

campo de acción tanto en su infraestructura,

arquitectura de componentes, servicios, backend,

plugins, librerías de terceros o las librerías propias

del framework, que se dispone a utilizar como base.

Fig. 4. Diagrama del flujo de datos (DFD) de un Sistema de

facturación, obtenida de https://es.slideshare.net/ Yaskelly

Yedra/diagrama-de-flujo-de-datos-dfd-59486803

Una práctica común que se recomienda es

identificar las interacciones con un DFD (Diagrama

de flujos de datos) (Ver Fig. 4), que nos permita

tener un concepto general del comportamiento de la

aplicación, esta herramienta permite exponer

visualmente cómo se planteó el software y que

posibles caminos tendría, según las decisiones

tomadas, las selecciones realizadas y las entradas

de datos que tenga el sistema; este proceso debe

partir de un análisis profundo de la ingeniería de

software, que se realizó previamente, utilizando las

herramientas como recursos humanos, casos de uso,

lenguaje unificado de modelado, notación para el

modelado de negocios (BPMN), diagramas de flujo

(DFD), obtención de requisitos, análisis,

especificaciones, arquitectura, programación, etc.

Cuando se identifican los límites del campo de

acción del software, podemos ver un panorama

claro de las necesidades reales, que podrían

https://es.slideshare.net/


7

presentarse para el equipo de desarrollo y

optimizarnos para ajustarnos a las necesidades

reales del cliente final. Cuando se plantea el diseño

inicial de los diferentes flujos de proceso,

identificamos las dependencias externas y la

interdependencia entre los orígenes de datos

necesarios, para satisfacer las demandas del sistema,

esta visión global nos permitira dar seguimiento a

las acciones y planear las diferentes actividades, que

nos permitirán desglosar un cronograma en el cual

registramos las actividades; así mismo se crea la

necesidad de llevar un documento, en el cual se

registre la información de los hallazgos y poder

tener información retrospectiva, para futuros

proyectos (Ver Tabla I).

Tabla I.

Ejemplo levantamiento de información dependencias externas [10].

Dependencias Externas

ID Descripción

1

En el sitio web de la biblioteca de la universidad se

ejecutará en un servidor Linux, que ejecute Apache. Este

servidor se reforzará según el estándar de endurecimiento

del servidor de la universidad. Esto incluye la aplicación del

último sistema operativo y parches de seguridad, de la

aplicación.

2

El servidor de la base de datos será MySQL y se ejecutará

en un servidor Linux. Este servidor se reforzará según el

estándar de endurecimiento del servidor de la universidad.

Esto incluirá la aplicación del último sistema operativo y

parches de seguridad de la aplicación.

3 La conexión entre el servidor web y el servidor de la base

de datos, se realizará a través de una red privada.

4 El servidor web está detrás de un firewall y la única

comunicación disponible es TLS.

B. Crear y analizar el Modelo de amenazas

Una vez se cuente con la información concreta del

funcionamiento e interacción de la aplicación con

los demás componentes, es necesario establecer una

retroalimentación, por lo menos con uno de los

participantes del proceso de cada disciplina de

desarrollo; esta reunión se debe enfocar en

encontrar amenazas concernientes al flujo normal

de los procesos de desarrollo, pero en ningún

momento el objetivo es dar una solución.

Según Microsoft [9], el siguiente paso es analizar

el DFD e identificar los puntos de entrada, los

límites de confianza, desde su punto inicial hasta el

final de su última ubicación, con el objetivo de

poder obtener una idea global de donde podrían

presentarse las amenazas, como lo es la

suplantación de identidad, la manipulación de datos,

la repudiación, la revelación de información, la

denegación de servicio, etc., con el fin de poder

realizar una comprobación y/o revisión de la

arquitectura, validando que se encuentren cubiertas

la mayoría de las amenazas. Una vez realizado este

proceso, se debe generar un documento donde se

tipifique los hallazgos identificados, junto con su

respectiva codificación para controlar cada una de

las etapas efectuadas.

A continuación, definiremos los ataques más

convencionales según el top 10 OWAPS móvil:

1) Controles débiles de lado servidor:

No se puede definir como un ataque en sí, pero

sus consecuencias negativas radican en el hecho de

que el dispositivo móvil sea un punto de entrada,

para que el servidor sea vulnerado generando un

impacto y brecha de seguridad técnica, en él

servidor.

Mitigación: La mitigación posible radica

principalmente en los encargados de la instalación y

mantenimiento de la infraestructura, en donde se

debe implementar una técnica que le brinde

seguridad a los diferentes componentes, tales como:

hardening (Aseguramiento de servidores), pruebas

de lógica de negocio, autenticación con niveles de

seguridad fuertes, configuraciones de servidor

robustas y evitar a toda costa, utilizar

configuraciones por defecto.

2) Almacenamiento inseguro de Datos:

Al tener acceso a la información de un dispositivo

por técnicas descuidadas en el proceso de

desarrollo, es posible que un atacante pueda

obtener: nombres de usuario, tokens de

autenticación, contraseñas, cookies, datos de

localización, nombre del id del dispositivo,

información personal, datos de la aplicación, etc.

Mitigación: La primera forma de mitigar este

riesgo, es no almacenar información relevante en el

dispositivo; hay que tener en cuenta como

desarrollador, que la perdida de datos es un factor

de alta gravedad para él usuario y que puede

generar un daño en la reputación de la compañía.


8

Una de las recomendaciones más difundidas

para el proceso de autenticación de forma segura, es

hacerlo a través de web o API; cuando sea necesario

almacenar información en el dispositivo, ya que no

hay más alternativas viables, se aconseja la

utilización de librerías de cifrado que permitan

ofuscar la información.

Cuando sea necesario cifrar la información de las

bases de datos tipo SQLite, el mercado cuenta con

herramientas tales como SQLite Encryption

Extension [11] o wsSQLite [12] y en lo posible

desactivar los permisos de lectura y escritura, en las

memorias del dispositivo.

3) Bajos niveles de protección en la capa de

transporte:

Cuando se diseña una aplicación, en la mayoría

de los casos se interactúa a nivel de cliente servidor;

por tal motivo la información es expuesta en

internet y podría ser accedida por terceros, que

podrían utilizarla para fines inescrupulosos.

Mitigación: La recomendación que brinda

OWASP, para identificar si estamos siendo

vulnerables, es realizar un análisis de tráfico por

proxy, utilizando herramientas como lo son BURN

[13] o ZAP OWASP [14], que nos permiten

analizar la información del tráfico de red y con sus

resultados podríamos hacernos las siguientes

preguntas: ¿Las conexiones están cifradas?, ¿Los

certificados SSL están vigentes?, ¿La fortaleza del

SSL es lo suficientemente robusta para ser

difícilmente descifrada?, una vez definido estos

interrogantes, las medidas a aplicar podrían ser:

• Utilizar certificado SSL / TLS para realizar

transporte de información entre cliente - servidor.

• Evitar sesiones mixtas de SSL, para no exponer

información importante de inicios de sesión con

API de terceros.

• Utilizar algoritmos de cifrado fuerte, con

longitudes de clave adecuadas.

• No usar certificados auto firmados.

• Validar la identificación del servidor cuando se

realice la conexión, utilizando certificados

confiables.

• Informar al usuario cuando la autenticación no

cumpla con los parámetros de seguridad y se haya

rehusado el certificado.

• No enviar información confidencial por canales

no seguros.

• Cifrar la información por separado antes de

utilizar el SSL, para evitar que posibles

vulnerabilidades de este protocolo, expongan la

información sensitiva del usuario u organización.

4) Fuga Involuntaria de Datos:

La falta de conocimiento en la forma que un

sistema operativo utiliza sus componentes de

memoria, podría convertirse en una herramienta

para que terceros accedan a información sensible de

un usuario; las aplicaciones podrían almacenar en

cache o en cookies, datos para su reutilización y si

no se tiene el cuidado correspondiente, ésta

información estará expuesta a otras aplicaciones o

malware instalados, en el dispositivo.

Mitigación: Conocer más a fondo la utilización

que hace el sistema operativo de las herramientas

como la cache de url, la cache del teclado, el

portapapeles (copiar/pegar), el almacenamiento de

datos (localstorage), las cookies del navegador y los

datos de analitycs.

La capacitación en estos temas, permitirá utilizar

más adecuadamente los recursos del sistema y

determinar si la exposición de datos a este tipo de

tecnologías, es adecuada o es necesario obtener los

datos de una forma más segura.

5) Pobres mecanismos de Autorización y/o

autenticación:

La autenticación en un sistema y la forma en que

se autorizan los perfiles de los usuarios, en algunas

ocasiones son descuidadas por los desarrolladores;

esto implicaría un problema de seguridad, ya que le

permitira a un atacante conectarse anónimamente a

un servicio y suplantar su identidad.

Mitigación: Para prevenir problemas en la

autenticación y en la autorización de los usuarios,

podríamos considerar los siguientes factores:


9

• Cuando una aplicación web se transfiere a una

móvil, debe contar con los mismos mecanismos de

autenticación (token).

• No se deben almacenar datos locales de

autenticación, en lo posible todas las solicitudes de

autenticación que se hagan del lado del servidor,

deben utilizar canales seguros de cifrados.

• La autenticación persistente debe usarse

opcionalmente, pero no debe ser aplicada por

defecto.

• No se debe utilizar Pin de 4 dígitos para la

autenticación, debido a que un atacante utilizando

tablas arcoíris, podría llegar a conocer fácilmente la

contraseña del sistema.

• Se debe validar y/o realizar comprobaciones de

código, que permitan detectar cambios en la

estructura, a causa de un ataque de binarios, el cual

puede llegar a modificar los mecanismos de

autenticación de la aplicación.

6) Uso inseguro de Criptografía:

Un atacante podría obtener acceso a la

información sensible de un usuario u organización,

intentando vulnerar el sistema de cifrado, debido a

que el algoritmo usado no es robusto, o el proceso

utilizado para la encriptación no cumpla con unos

estándares mínimos, que ofrezcan un nivel de

protección adecuado, un manejo deficiente de las

llaves de encriptación, también es un factor de

vulnerabilidad, sin importar la efectividad y

fortaleza del algoritmo, que se utilice una mala

selección de este recurso puede desencadenar, en

que un atacante ingrese al sistema.

El uso de algoritmos propios de cifrado, también

es una mala práctica debido a que el nivel de

evaluación para comprobar su efectividad, podría

no ser el suficiente.

7) Inyección del lado del cliente:

Las aplicaciones en general tienen mecanismos

de entrada que permiten la interacción con el

usuario (input), en este proceso un atacante podría

enviar datos no confiables, que alteren el

funcionamiento esperado del sistema; estos datos

podrían estar mal formados y debido a la falta de

validación, los procesaría de una forma subyacente,

en un contexto diferente para el que fue diseñado.

Entre los ataques más comunes podríamos

encontrar:

• Inyección de SQL: Este ataque está enfocado a

ejecutarse en el contexto de una base de datos,

donde él atacante intenta agregar información a una

consulta SQL; desde una entrada de interfaz o

navegador tratando de acceder a la información del

sistema, por medio del incorrecto chequeo o filtrado

de variables (Ver Fig. 5).

Fig. 5.Ejemplo de ataque de inyección de SQL, obtenida de:

https://www.securityartwork.es/2013/11/21/evasion-de-

autenticacion-con-inyeccion-sql/

• Inyección de javascript (XSS): Los navegadores

móviles son también vulnerables a este ataque, que

consiste en inyectar código JavaScript por medio de

la barra del navegador (Ver Fig. 6), o encontrando

una vulnerabilidad de XSS (Cross-site scripting).

Fig. 6.Ejemplo de Ataque XSS, obtenida de:

https://dotnetcoretutorials.com/2017/10/25/owasp-top-10-asp-net-

core-cross-site-scripting-xss/

• Código Binario: Un malware u otra aplicación

maliciosa, podrían realizar un ataque binario contra

la capa de presentación (HTML, Javascript, CSS) y

ejecutar código malicioso, en tiempo de ejecución

de la aplicación.

Mitigación: Para mitigar este tipo de ataque, es

fundamental la correcta validación de los campos,


10

así mismo como la parametrización de los datos que

se envían a la base datos como consulta. Se debe

restringir los permisos a los navegadores móviles,

cuando se construye la aplicación para evitar que se

ejecuten archivos locales desde esta instancia.

8) Decisiones de seguridad a través de entradas no

confiables:

Las aplicaciones utilizan mecanismos de

autenticación, para diferenciar los usuarios de nivel

superior de los de nivel inferior. Una mala

implementación de IPC [3], podría permitir que un

atacante intercepte las llamadas y obtenga

información sensible del sistema.

Mitigación: Se debe usar listas blancas de

aplicaciones de confianza que validen la

comunicación entre procesos.

Validar de parte del usuario las acciones

sensibles que se ejecuten, a través de puntos de

entrada IPC.

Validar la información que se ingrese por IPC,

para evitar ataques dirigidos.

Evitar en lo posible transmitir información

sensible por canales IPC, para que no pueda ser

leída por terceros.

9) Manejo incorrecto de sesión:

Generalmente cuando realizamos operaciones

cliente servidor, se usan tokens para mantener el

estado sobre los protocolos HTTP y SOAP, cuando

existe una autenticación exitosa el servidor, entrega

una cookie de sesión que sirve para validar toda

operación, que se ejecute mientras el usuario se

encuentre logueado y se solicita para los diferentes

request de operación. El peligro de esta

vulnerabilidad, consiste en compartir esta

información a un tercero que podría suplantar

nuestra identidad.

Mitigación: Invalidar sesión no solamente en el

lado de la aplicación (front-end), sino también en el

servidor (back-end), el error de permitir este

comportamiento podría generar, que un atacante

obtenga la información de sesión y hacerse pasar

por el usuario, que ha finalizado su sesión desde el

dispositivo móvil.

• Falta de protección adecuada en el tiempo de

espera. Cuando una aplicación se ha logueado en un

servidor, tiene un tiempo de inactividad para cerrar

la sesión, con lo cual pierde validez el token de

sesión, así, se evita que un tercero pueda obtener

acceso y asuma el control del rol del usuario. Según

OWASP, se recomienda que el tiempo de

finalización de sesión por inactividad sea de 15

minutos en aplicaciones críticas, de 30 minutos en

aplicaciones de seguridad media y de 1 hora en

aplicaciones de baja seguridad. Actualmente

muchas aplicaciones mantienen su sesión iniciada,

para darle mayor facilidad a los usuarios y depende

únicamente del factor de autenticación que ofrece el

móvil (huella, pin, reconocimiento facial, patrón,

etc.); por esta razón, se debe analizar sí, estos

controles son suficientes o se deben agregar otros

mecanismos de autenticación; esto en si dependerá

directamente del criterio del desarrollador, la

necesidad del usuario y la criticidad de los datos.

• Restablecer cookies al generarse un cambio de

estado en la autenticación. Es necesario tener en

cuenta el cambio de estado de las cookies, para

destruirlas en el lado del servidor y no deben

aceptarse las de sesiones anteriores, que ya hayan

expirado en su validez.

• Generación de Tokens seguros. Los

desarrolladores deben utilizar métodos aceptados

que sean estándar, deben tener una longitud

apropiada, complejidad y pseudo aleatorios, para

evitar que sea fácil para un atacante adivinar el

patrón.

10) Falta de protección Binaria:

Un atacante podría realizar ingeniería inversa a

una aplicación, con el fin de entender su

funcionamiento y poder realizar cambios a nivel

binario; la mayor susceptibilidad radica en alojar en

el código en ambientes no seguros, que permitan

observar el funcionamiento en tiempo real del

aplicativo, tales como clientes móviles o el

firmware en los dispositivos. En términos prácticos,

cualquier aplicación instalada, en cualquier tipo de

dispositivo es vulnerable a un ataque de este tipo.

Mitigación: Para poder mitigar este tipo de


11

ataques es necesario tomar medidas, que detecten

cambios en la estructura del sistema operativo y del

código, tales como:

a) Controles de detección de jailbreak.

b) Controles de ckecksum.

c) Certificado de fijación de controles.

d) Controles de detección de depurador, que en

tiempo real detecte cambios en el código.

e) Desarrollar aplicaciones para evitar análisis de

ingeniería inversa con técnicas de análisis estáticas

o dinámicas.

C. Analizar las amenazas

Una vez completada la identificación de las

posibles amenazas que podría presentar el software,

se debe dar valor al riesgo de cada una de los

hallazgos encontrados, determinando posibilidad

del daño, posibilidad de reproducción de la

amenaza, posibilidad de poder explotar la

vulnerabilidad, usuarios afectados y su

descubrimiento en caso que se pueda materializar

un ataque, tomando las medidas necesarias para

poder mitigar el riesgo o aplicar las conductas

necesarias, que puedan ser documentadas

claramente para el equipo de trabajo.

D. Proceso Identificar técnicas y tecnologías de

mitigación

Una vez se han identificado las amenazas a las

que se encuentra expuesta la aplicación, se deben

determinar que posibles técnicas podrían aplicarse

para contrarrestar el efecto de un posible ataque.

En el numeral VI. B se puede identificar las

amenazas del TOP 10 de OWASP, en las cuales se

describen los factores más trascendentales, que se

pueden presentar en el desarrollo móvil y las

posibles buenas prácticas, que permitan mejorar los

aspectos de seguridad en estos temas, teniendo en

cuenta que la elección de las tecnologías, debe ser

enfocada a los objetivos de la empresa y

presupuestos aprobados para esta.

E. Documentar el modelo de seguridad

El éxito de aplicar un modelo TMA de análisis de

amenazas, consiste en la documentación de los

hallazgos que se obtienen al realizar todo el

proceso, este factor implica poder dejar evidencia

de todo el análisis, para que posteriormente pueda

ser utilizada para dar soporte, realizar pruebas,

efectuar control de calidad (QA) y ofrecerá ayuda,

técnica en el siguiente proceso de implementación

de la infraestructura, para la correcta ejecución de la

aplicación.

F. Implementar y probar Mitigaciones

Es fundamental que en caso de que se materialice

una amenaza, sea probado y ajustado el plan de

acción, para llegar a un punto final que proporcione

un nivel adecuado de protección, que mitigue

efectivamente el riesgo.

G. Mantener el modelo de amenazas sincronizado

con el diseño

Debemos tener claro que las aplicaciones tienen

un ciclo de vida, esto le permite ir en crecimiento y

agregar nuevos componentes, suprimir otros e

integrarse con nuevas tecnologías, es necesario estar

en una continua verificación, que permita identificar

nuevos hallazgos e ir ajustándolo, haciendo que el

sistema madure.

VII. CONTROLES

Para poder mantener un proceso de desarrollo

seguro, es necesario implementar controles que den

seguimiento y evaluación, que puedan medir la

eficacia de las medidas aplicadas; si nos apegamos a

la definición que brinda ISACA, la cual define el

control como el medio para gestionar el riesgo,

incluidas las políticas, procedimientos, directrices,

prácticas y estructuras organizativas, que pueden ser

de naturaleza administrativa, técnica o legal [15],

entendemos la necesidad de implementar

mecanismos, que nos ayuden a ponerlos en

funcionamiento, por esta razón podemos utilizar

como guía el numeral 14.2 de la sección de

controles de la norma ISO 27001. Algunos de los

más importantes son los siguientes:

A. Políticas de desarrollo Seguro

La organización debe estar completamente

comprometida, a realizar todo lo necesario para que

sus productos de desarrollo sean seguros, las

políticas permitirán erigir los lineamientos y serán

el punto de partida, para que todos los integrantes

del proceso tengan conciencia de que existe una

necesidad y compromiso, de ofrecer productos

confiables.

B. Procedimientos de Control

Las políticas son el punto de partida de cualquier

proceso que desee implementar seguridad, pero el


12

cómo aplicarlos se identifica en los procedimientos.

La compañía u organización debe mantener

manuales de las practicas que se deben realizar para

aplicar los modelos como el TMA y probar la

eficacia de estos, actualizándolos nuevamente

cuando se presenten cambios en la plataforma,

garantizando su correcto funcionamiento. Estos

procedimientos deben mantener unos principios de

desarrollo seguro, donde los integrantes del equipo

puedan socializar, entender la necesidad y se ajusten

a los lineamientos de la compañía.

C. Ambientes seguros de desarrollo

El éxito de que se mantenga la información y la

propiedad intelectual, radica en poder controlar los

entornos de desarrollo, cada organización debe

contar con herramientas que sean de tipo lógico y

físico, que mantengan a salvo los recursos utilizados

en las prácticas de desarrollo.

Además de los controles generales expuestos en

la norma técnica ISO 27001, OWASP nos brinda 10

controles generales, que podemos implementar para

el desarrollo de Software, los cuales se enumeran a

continuación:

1) Parchado.

2) Implementación de sistemas de Cortafuegos.

3) Validaciones en las entradas de los programas.

4) Escáner de vulnerabilidades.

5) Manejo adecuado y profundo de mensajes de

error.

6) Manejo y escalabilidad en los integrantes

proceso desarrollo.

7) Análisis de código seguro.

8) Analizar los procesos de seguridad de terceros.

9) Endurecimiento de la configuración de la base de

datos.

10) Capacitar al personal que desarrolle

aplicaciones, para escritura desarrollo seguro.

VIII. CONCLUSIONES

El desarrollo seguro, es una necesidad en toda

organización, la implementación es un proceso de

compromiso y debemos enfocarnos a cumplir con

una serie de requisitos, de los cuales podríamos

destacar como más importantes los siguientes:

1) Crear la conciencia de la necesidad de desarrollo

seguro.

2) Crear políticas que puedan dar bases para la

creación de todo el proceso.

3) Crear los procedimientos que puedan aplicarse en

cada etapa del desarrollo y sean la base de

seguimiento de los equipos participantes.

4) Identificar los riesgos inherentes a cada proyecto.

5)Crear un plan de mitigación de los riesgos

inherentes del proyecto.

6) Dar seguimiento y control en las etapas de

desarrollo.

7) Ajustar y corregir los lineamientos a medida que

avance el proyecto, buscando retroalimentar a los

integrantes en todas sus etapas.

8) Documentar todos los procesos, en cada etapa del

desarrollo del producto.

REFERENCIAS

[1] OWASP, «https://www.owasp.org,» [En línea]. Available:

https://www.owasp.org/index.php/About_The_Open_Web_Ap

plication_Security_Project.


https://www.owasp.org/index.php/Mobile_Security_Project_A

rchive#tab=Top_10_Mobile_Risks. [Último acceso: 24 05

2018].

[3] RAE, «REAL ACADEMIA ESPAÑOLA,» 2017. [En

línea]. Available: http://dle.rae.es/?id=A8mrPcH. [Último

acceso: 30 05 2018].

[4] Análisis de Riesgos I. O. f. Standardization, ISO/IEC

27001, Ginegra Suiza, 2013.


https://www.owasp.org/index.php/Category:Threat_Model

ing. [Último acceso: 24 05 2018].

[6] M. Corporation, «https://docs.microsoft.com,» [En línea].

Available: https://msdn.microsoft.com/es-

es/library/aa561499(v=bts.10).aspx. [Último acceso: 01 06

2018].


https://www.owasp.org/index.php/Application_Threat_Modeli

ng. [Último acceso: 27 05 2018].

[8] M. Corporation, «https://docs.microsoft.com,» [En línea].

Available: https://msdn.microsoft.com/es-

es/library/aa561499(v=bts.10).aspx. [Último acceso: 01 06

2018].

[9] J. A. Kreibich, «Sqlite,» hwaci, [En línea]. Available:

http://www.hwaci.com/sw/sqlite/ams.html. [Último acceso: 03

06 2018].

[10] u/blackpaw, «https://sourceforge.net,» [En línea].

Available: https://sourceforge.net/projects/wxsqlite/. [Último

acceso: 29 05 2018].


13

[11] PORTSWIGGER, «portswigger.net,» [En línea].

Available: https://portswigger.net/burp/. [Último acceso: 28 05

2018].


https://www.owasp.org/index.php/OWASP_Zed_Attack_Prox

y_Project. [Último acceso: 27 05 2018].

[13] ISACA, «ISACA.ORG,» [En línea]. Available:

https://www.isaca.org/Pages/Glossary.aspx?tid=2011&char=C

. [Último acceso: 01 06 2018].


https://www.owasp.org/index.php/Category:Control. [Último

acceso: 27 05 2018].

Autor:

Johann Harry Lopez Vargas Ingeniero de Sistemas de la

Corporación Universitaria Remington, Desarrollador de

Software de profesión, con experiencia de más de 5 años en

lenguajes de programación, desarrollando aplicaciones para

dispositivos móviles, entornos web y escritorio, participando

tanto en proyectos particulares como con entidades del estado,

desempeñándose actualmente en el sector financiero.

DESARROLLO SEGURO DE APLICACIONES MÓVILES APLICANDO ...

Documents

Transcript of DESARROLLO SEGURO DE APLICACIONES MÓVILES APLICANDO ...