Technique de codage sécurisé : Le problème des autorisations personnalisées

Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Elles peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou à la capacité d'envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plateforme, définies par le framework Android.

Mais il existe des cas où celles-ci ne suffisent pas et où l'application doit définir sa propre autorisation personnalisée. Prenons notre propre entreprise comme exemple. Secure Code Warrior pourrait créer une application qui enregistre des données privées dans le cadre d'un profil, notamment les performances de l'utilisateur sur la plateforme SCW. Nous souhaiterions permettre à une autre application de formation à la sécurité, disons DevTrainer, d'utiliser ces données si l'utilisateur lui en donne l'autorisation. Il s'agit de données sensibles que l'utilisateur ne voudrait certainement pas voir divulguées à n'importe qui, mais la SCWApp ne devrait pas non plus les masquer et les protéger totalement, car elles pourraient être utiles. Nous souhaitons donc laisser l'utilisateur garder le contrôle. C'est là qu'interviennent les autorisations personnalisées.

La SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite l'accorder ou non. C'est une pratique courante et un bon moyen de restreindre l'accès aux applications figurant sur liste blanche.

Malheureusement, certains comportements contre-intuitifs liés aux autorisations personnalisées les rendent risquées d'un point de vue sécuritaire. Concrètement, des autorisations personnalisées peuvent être définies par n'importe quelle application à tout moment, et la règle du « premier arrivé, premier servi » s'applique, ce qui entraîne certaines conséquences.

Pour le scénario suivant, nous définissons deux profils d'application présentés ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :

1. SCWApp : l'application qui définit une autorisation personnalisée et protège un composant à l'aide de cette autorisation.

2. DevTrainer : cette application définit la même autorisation que SCWApp et déclare à l'utilisateur qu'elle souhaite détenir cette autorisation.

Il s'agit d'un scénario courant appelé le cas des applications homologues. Si l'application DevTrainer n'était qu'un plugin pour la SCWApp, elle n'aurait pas besoin de définir l'autorisation personnalisée. L'hypothèse, dans ce cas, est que la SCWApp serait installée avant DevTrainer et qu'aucun comportement inattendu ne se produirait. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite la SCWApp, DevTrainer ne reçoit pas l'autorisation de manière rétroactive, de sorte que les tentatives de l'application DevTrainer d'utiliser le composant sécurisé échoueront.

C'est là qu'intervient le cas des applications homologues. Dans certains cas, on ne peut pas s'attendre à ce qu'une application soit installée avant l'autre. Par exemple, si Facebook et Twitter souhaitent tous deux utiliser les composants de l'autre, ils doivent définir leurs autorisations personnalisées respectives.

Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.

Cela devient encore plus délicat. L'application DevTrainer peut modifier le niveau de protection de l'autorisation. Android n'utilise pas le niveau de protection du défenseur, mais celui défini en premier, ce qui signifie que l'application installée en premier peut le définir. Ainsi, si DevTrainer modifie le niveau d'autorisation en « normal », toute application future demandant cette autorisation n'aura pas besoin de confirmation de la part de l'utilisateur et se verra automatiquement accorder l'accès.

Ce scénario a été inspiré par l'explication de ce problème trouvée sur le dépôt GitHub cwac-security.

La stratégie du « premier arrivé, premier servi » a des conséquences dangereuses, et ignorer ce comportement peut amener le développeur à prendre des décisions de sécurité basées sur des entrées non fiables, permettant à des applications non intentionnelles d'accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter les décisions de sécurité basées sur des entrées non fiables, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais comme actuellement, plus de 22 % des appareils Android utilisent encore une version antérieure, il est important d'atténuer les risques liés au comportement initial dans votre application. Vérifiez si l'autorisation a déjà été définie lors du premier lancement de votre application et prenez les mesures appropriées pour résoudre tout risque de sécurité.

Bon codage et à la semaine prochaine !

En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.

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