Técnica de programación segura: El problema de los permisos personalizados

Al desarrollar para dispositivos móviles, las aplicaciones a menudo deben solicitar ciertos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.

Pero hay casos en los que estos no son suficientes y la aplicación necesita definir sus propios permisos personalizados. Usaré a nuestra propia empresa como ejemplo. Secure Code Warrior podría crear una aplicación que guarde datos privados como parte de un perfil, incluido el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario les da permiso para hacerlo. Se trata de datos confidenciales, el usuario ciertamente no querría que cualquiera los conociera, pero la aplicación de SCW no debería ocultarlos y protegerlos por completo, ya que podrían ser útiles. Por lo tanto, queremos que el usuario tenga el control sobre ellos. Aquí es donde entran en juego los permisos personalizados.

La aplicación de SCW crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si desea permitirlo o no. Esta es una práctica común y una buena forma de restringir el acceso a aplicaciones incluidas en una lista blanca.

Desafortunadamente, existen algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, cualquier aplicación puede definir permisos personalizados en cualquier momento, y "el primero que llega gana", una estrategia que conlleva ciertas consecuencias.

Para el siguiente escenario, definimos dos perfiles de aplicación que presentamos anteriormente (todas estas aplicaciones son ficticias con fines demostrativos):

1. SCWApp: la aplicación que define un permiso personalizado y protege un componente utilizando este permiso.

2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea obtener este permiso.

Este es un escenario común denominado el caso de aplicaciones pares. Si la aplicación DevTrainer fuera solo un complemento para SCWApp, no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no ocurrirá ningún comportamiento inesperado. Si de alguna manera el usuario instala DevTrainer primero, no se le informa sobre la solicitud de permiso. Si el usuario instala SCWApp más tarde, a DevTrainer no se le otorga el permiso retroactivamente, por lo que los intentos de la aplicación DevTrainer de utilizar el componente protegido fallarán.

Aquí es donde entra en juego el caso de aplicaciones pares. En algunos casos, no se puede esperar que una aplicación se instale antes que la otra. Por ejemplo, si Facebook y Twitter quieren usar los componentes del otro, tienen que definir los permisos personalizados del otro.

Sin embargo, aquí es donde se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado sobre su solicitud de permiso personalizado. En este punto, aunque el usuario no fue informado, DevTrainer posee el permiso personalizado y puede acceder al componente protegido.

Se vuelve aún más complicado. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que cualquier aplicación que se haya instalado primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le otorgará acceso automáticamente.

Este escenario se inspiró en la explicación de este problema que se encuentra en el github de cwac-security.

La estrategia de "el primero que llega gana" tiene consecuencias peligrosas y no conocer su comportamiento podría llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no confiables y permitir que aplicaciones no deseadas accedan a datos confidenciales o servicios protegidos. Para obtener más información sobre cómo evitar decisiones de seguridad mediante entradas no confiables, visite nuestra plataforma. Este comportamiento cambió a partir de Android 5.0 (Lollipop). Pero dado que actualmente, más del 22% de los dispositivos Android todavía ejecutan una versión inferior de Android, es importante mitigar los riesgos del comportamiento original en su aplicación. Compruebe si el permiso ya se ha definido en la primera ejecución de su aplicación y tome las medidas adecuadas si este es el caso para resolver cualquier riesgo de seguridad.

¡Buena suerte programando y nos vemos la próxima semana!

Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.

https://developer.android.com/guide/topics/permissions/defining.html