Cette section contient des recommandations pour garantir la sécurité des applications sur les appareils Android.
Révision 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 fortement la révision manuelle et automatisée du code source.
- Suivez les directives de sécurité complètes lorsque vous effectuez des examens pour garantir la couverture. Utiliser des 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 tous 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 tampon et les erreurs ponctuelles.
- Le système de build Android prend en charge de nombreux désinfectants LLVM, tels que AddressSanitizer et UndefinedBehaviorSanitizer , qui peuvent être utilisés pour l'analyse d'exécution des problèmes liés à la mémoire. Combinés au fuzzing, pris en charge dans Android via libFuzzer , les désinfectants peuvent découvrir des cas extrêmes inhabituels nécessitant une enquête plus approfondie.
- Un évaluateur de sécurité compétent doit examiner les codes à risque plus élevé, tels que la cryptographie, le traitement des paiements et le traitement des informations personnelles.
Tests automatisés
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 de CTS tout au long du processus de développement pour détecter les problèmes plus tôt et réduire le temps de correction. Android utilise CTS dans le cadre d'une intégration continue dans notre processus de génération automatisé, qui est généré 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 build d'Android prend en charge libFuzzer pour écrire des tests fuzz.
Analyse des vulnérabilités
L'analyse des vulnérabilités peut contribuer à garantir que les applications préinstallées sont exemptes de vulnérabilités de sécurité connues. La détection avancée peut réduire le temps et les coûts nécessaires pour remédier à ces vulnérabilités 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 vulnérabilités des applications reconnu par l'industrie et corrigez les vulnérabilités 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 à la recherche de vulnérabilités.
Pour plus d'informations sur les PHA et la manière dont Google les combat dans le Play Store, consultez la documentation du développeur Google Play Protect .
Installation et autorisations de l'application
Des autorisations excessives pour les applications préinstallées peuvent créer un risque de sécurité. Limitez les applications préinstallées aux autorisations minimales nécessaires et assurez-vous qu’elles n’ont pas accès à des autorisations ou privilèges inutiles. Les autorisations des applications sont décrites dans AndroidManifest.xml .
- N'accordez pas d'autorisations ou de privilèges inutiles aux applications préinstallées. Examinez attentivement les applications dotées de privilèges système, car elles peuvent disposer d'autorisations très sensibles.
- Assurez-vous que toutes les autorisations demandées sont pertinentes et nécessaires au fonctionnement de cette application spécifique.
- Assurez-vous qu'il y a une divulgation des utilisateurs pour 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 avec l'UID 0.
- Évaluez les autorisations déclarées dans le 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 de navigation sécurisée de Google avant de diffuser des applications sur l'appareil.
Signature d'application
Les signatures d'applications jouent un rôle important dans la sécurité des appareils et sont utilisées pour les vérifications d'autorisations et les mises à jour logicielles. Lors de la sélection d'une clé à utiliser pour signer des applications, il est important de déterminer si une application sera disponible uniquement sur un seul appareil ou si elle sera commune à plusieurs appareils.
- Assurez-vous que les applications ne sont pas signées avec une clé publiquement connue, telle que la clé de développeur AOSP.
- Assurez-vous que les clés utilisées pour signer les applications sont gérées de manière cohérente avec les pratiques standard du secteur en matière de gestion des clés sensibles, y compris un module de sécurité matérielle (HSM) qui fournit un accès limité et vérifiable.
- Assurez-vous que les applications ne sont pas signées avec la clé de plateforme. Cela donne à une application l'accès aux autorisations de signature de plate-forme, qui sont très puissantes et destinées uniquement à être utilisées 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 lors de la création d’une application pour différents appareils, notamment lors de l’utilisation de la clé de plateforme. 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 sandboxing Android offre une sécurité supplémentaire autour des applications et des processus lorsqu'il est utilisé correctement.
Isoler les processus racine
Les processus racine sont la cible la plus fréquente des attaques par élévation de privilèges ; la réduction du nombre de processus racine réduit le risque d’élévation des privilèges.
- Assurez-vous que les appareils exécutent le code minimum nécessaire en tant que root. Dans la mesure du possible, utilisez un processus Android classique plutôt qu'un processus racine. Si un processus doit s'exécuter en tant que root sur un appareil, documentez le processus 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 interprocessus (IPC). 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 de runtime à usage général, tel qu'une machine virtuelle 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 du système (UID) partagé. S'il est nécessaire qu'une application utilise l'UID partagé du système ou un autre service privilégié (par exemple, un téléphone), l'application ne doit exporter aucun service, récepteur de diffusion ou fournisseur de contenu accessible par des applications tierces installées par les utilisateurs. .
- Assurez-vous que les appareils exécutent le code minimum nécessaire en tant que système. Dans la mesure du possible, utilisez un processus Android avec son propre UID plutôt que 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 exposer IPC uniquement à d'autres processus fiables.
- Les processus système ne doivent pas écouter sur une socket réseau. Il s’agit d’une exigence du CTS.
Processus d'isolation
Le bac à sable d'application Android fournit aux applications une attente d'isolation des autres processus du système, y compris les processus racine et les débogueurs. À moins que le débogage ne soit spécifiquement activé par l'application et l'utilisateur, aucune application ne doit violer cette attente.
- Assurez-vous que les processus racine n'accèdent pas aux données contenues dans des dossiers de données d'application individuels, à moins d'utiliser 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 en utilisant une méthode de débogage Android documentée.
- Assurez-vous que les appareils n’incluent aucune application accédant aux données ou à la mémoire d’autres applications ou processus.