Cette section contient des recommandations pour assurer la sécurité des applications sur les appareils Android.
Examen du code source
L'examen du code source peut détecter un large éventail de problèmes de sécurité, y compris ceux identifiés dans ce document. Android encourage vivement l'examen manuel et automatisé du code source.
- Suivez des consignes de sécurité complètes lorsque vous effectuez des examens pour assurer la couverture. Utilisez les normes internes ou externes pertinentes pour garantir des examens cohérents et complets.
- Exécutez un linter, tel que le linter Android Studio, sur tout le code de l'application à l'aide du SDK Android et corrigez les problèmes identifiés.
- Analysez le code natif à l'aide d'un outil automatisé capable de détecter les problèmes de gestion de la mémoire, tels que les dépassements de mémoire tampon et les erreurs de décalage d'une unité.
- Le système de compilation Android est compatible avec de nombreux outils de vérification LLVM, tels que AddressSanitizer et UndefinedBehaviorSanitizer, qui peuvent être utilisés pour l'analyse de l'exécution des problèmes liés à la mémoire. Combinés au fuzzing, pris en charge dans Android via libFuzzer, les outils de vérification peuvent révéler des cas extrêmes inhabituels nécessitant une enquête plus approfondie.
- Un évaluateur de sécurité compétent doit examiner le code à risque élevé, tel que le traitement du chiffrement, des paiements et des informations permettant d'identifier personnellement l'utilisateur.
Tests automatiques
Les tests automatisés peuvent aider à détecter un large éventail de problèmes de sécurité et doivent être effectués régulièrement.
- Exécutez régulièrement la dernière version du CTS tout au long du processus de développement pour détecter les problèmes à un stade précoce et réduire le temps de correction. Android utilise le CTS dans le cadre de l'intégration continue de notre processus de compilation automatisé, qui est exécuté plusieurs fois par jour.
- Automatisez les tests de sécurité des interfaces, y compris les tests avec des entrées mal formées (fuzz testing). Le système de compilation d'Android est compatible avec libFuzzer pour l'écriture de tests de fuzzing.
Analyse des failles
L'analyse des failles peut permettre de s'assurer que les applications préinstallées ne présentent pas de failles de sécurité connues. La détection avancée peut réduire le temps et les coûts nécessaires pour remédier à ces failles et prévenir les risques pour les utilisateurs et les appareils.
- Analysez toutes les applications préinstallées à l'aide d'un outil d'analyse des failles d'application reconnu par le secteur et corrigez les failles détectées.
Applications potentiellement dangereuses
Il est important de s'assurer que les applications préinstallées sur votre appareil ne sont pas des applications potentiellement dangereuses (PHA). Vous êtes responsable du comportement de toutes les applications incluses sur vos appareils. Avant le lancement de l'appareil, analysez toutes les applications préchargées pour détecter les failles.
Pour en savoir plus sur les PHA et sur la façon dont Google les combat sur le Play Store, consultez la documentation pour les développeurs Google Play Protect.
Installation et autorisations des applications
Des autorisations excessives pour les applications préinstallées peuvent créer un risque pour la sécurité. Limitez les autorisations des applications préinstallées au minimum nécessaire et assurez-vous qu'elles n'ont pas accès à des autorisations ou privilèges inutiles. Les autorisations de l'application sont décrites dans le fichier AndroidManifest.xml.
- N'accordez pas d'autorisations ni de droits inutiles aux applications préinstallées. Examinez attentivement les applications disposant de privilèges système, car elles peuvent avoir des autorisations très sensibles.
- Assurez-vous que toutes les autorisations demandées sont pertinentes et nécessaires au fonctionnement de l'application concernée.
- Assurez-vous que les utilisateurs sont informés de toutes les applications préinstallées qui utilisent l'autorisation
INSTALL_PACKAGES
. - Assurez-vous que le développeur est contractuellement tenu de ne pas installer d'applications en tant qu'UID 0.
- Évaluez les autorisations déclarées dans le fichier manifeste de toutes les applications à installer via le réseau du développeur.
- Assurez-vous que le développeur est contractuellement tenu d'analyser toutes les URL de téléchargement des applications de mise à jour automatique et d'installation avec l'API Google Safe Browsing avant de proposer les applications sur l'appareil.
Signature d'application
Les signatures d'application jouent un rôle important dans la sécurité des appareils. Elles sont utilisées pour les vérifications des autorisations et les mises à jour logicielles. Lorsque vous sélectionnez une clé à utiliser pour signer des applications, il est important de déterminer si une application n'est disponible que sur un seul appareil ou si elle est courante sur plusieurs appareils.
- Assurez-vous que les applications ne sont pas signées avec une clé publique connue, comme la clé de développeur AOSP.
- Assurez-vous que les clés utilisées pour signer les applications sont gérées conformément aux pratiques standards du secteur pour la gestion des clés sensibles, y compris un module de sécurité matérielle (HSM) qui fournit un accès limité et auditable.
- Assurez-vous que les applications ne sont pas signées avec la clé de plate-forme. Cela donne à une application l'accès aux autorisations de signature de la plate-forme, qui sont très puissantes et ne sont destinées à être utilisées que par les composants du système d'exploitation. Les applications système doivent utiliser des autorisations privilégiées.
- Assurez-vous que les applications portant le même nom de package ne sont pas signées avec des clés différentes. Cela se produit souvent lorsque vous créez une application pour différents appareils, en particulier lorsque vous utilisez la clé de plate-forme. Si l'application est indépendante de l'appareil, utilisez la même clé sur tous les appareils. Si l'application est spécifique à un appareil, créez des noms de package uniques par appareil et par clé.
Isoler les applications et les processus
Le modèle de bac à sable d'Android offre une sécurité supplémentaire aux applications et aux processus lorsqu'il est utilisé correctement.
Isoler les processus racine
Les processus racine sont la cible la plus fréquente des attaques d'élévation des privilèges. La réduction du nombre de processus racine diminue le risque d'élévation des privilèges.
- Assurez-vous que les appareils exécutent le code minimal nécessaire en tant que racine. Dans la mesure du possible, utilisez un processus Android standard plutôt qu'un processus racine. Si un processus doit s'exécuter en tant que root sur un appareil, documentez-le dans une demande de fonctionnalité AOSP afin qu'il puisse être examiné publiquement.
- Dans la mesure du possible, le code racine doit être isolé des données non fiables et accessible via la communication entre processus (IPC, interprocess communication). Par exemple, réduisez la fonctionnalité racine à un petit service accessible via Binder et exposez le service avec une autorisation de signature à une application avec peu ou pas de privilèges pour gérer le trafic réseau.
- Les processus racine ne doivent pas écouter sur un socket réseau.
- Les processus racine ne doivent pas inclure d'environnement d'exécution à usage général, tel qu'une VM Java.
Isoler les applications système
En général, les applications préinstallées ne doivent pas s'exécuter avec l'identifiant unique (UID) du système partagé. Si une application doit utiliser l'UID partagé du système ou d'un autre service privilégié (par exemple, le téléphone), elle ne doit exporter aucun service, broadcast receiver ni fournisseur de contenu accessible par des applications tierces installées par les utilisateurs.
- Assurez-vous que les appareils exécutent le code minimal nécessaire en tant que système. Dans la mesure du possible, utilisez un processus Android avec son propre UID au lieu de réutiliser l'UID du système.
- Dans la mesure du possible, le code système doit être isolé des données non fiables et n'exposer l'IPC qu'à d'autres processus fiables.
- Les processus système ne doivent pas écouter sur un socket réseau. Il s'agit d'une exigence CTS.
Isoler les processus
Le bac à sable de l'application Android permet aux applications de s'attendre à être isolées des autres processus du système, y compris des processus racine et des débogueurs. À moins que le débogage ne soit spécifiquement activé par l'application et l'utilisateur, aucune application ne doit enfreindre cette attente.
- Assurez-vous que les processus racine n'accèdent pas aux données dans les dossiers de données des applications individuelles, sauf s'ils utilisent une méthode de débogage Android documentée.
- Assurez-vous que les processus racine n'accèdent pas à la mémoire des applications, sauf s'ils utilisent une méthode de débogage Android documentée.
- Assurez-vous que les appareils n'incluent aucune application qui accède aux données ou à la mémoire d'autres applications ou processus.