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 les consignes de sécurité complètes lors des examens pour assurer la couverture. Utilisez des normes internes ou externes pertinentes pour garantir des examens cohérents et complets.
- Exécutez un analyseur lint, tel que l'analyseur lint Android Studio, sur tout le code de l'application à l'aide du SDK Android, puis 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'un bit.
- Le système de compilation Android est compatible avec de nombreux outils de nettoyage 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, compatible avec Android via libFuzzer, les outils de nettoyage peuvent détecter des cas particuliers inhabituels nécessitant une enquête plus approfondie.
- Un évaluateur de sécurité compétent doit examiner le code à risque plus élevé, comme la cryptographie, le traitement des paiements et le traitement 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 de 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 CTS dans le cadre de l'intégration continue dans notre processus de compilation automatisé, qui effectue des compilations plusieurs fois par jour.
- Automatisez les tests de sécurité des interfaces, y compris les tests avec des entrées mal formées (tests de fuzz). Le système de compilation d'Android est compatible avec libFuzzer pour écrire des tests fuzz.
Analyse des failles
L'analyse des failles peut vous aider à vous 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 éviter 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 l'industrie et corrigez les failles détectées.
Applications potentiellement dangereuses
Il est important de vous 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, recherchez les failles dans toutes les applications préchargées.
Pour en savoir plus sur les applications potentiellement dangereuses et sur la façon dont Google les combat sur le Play Store, consultez la documentation destinée aux développeurs sur Google Play Protect.
Installation et autorisations des applications
Des autorisations excessives pour les applications préinstallées peuvent présenter un risque de sécurité. Limitez les autorisations minimales nécessaires aux applications préinstallées et assurez-vous qu'elles n'ont pas accès à des autorisations ou à des 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 droits d'accès 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'une notification est envoyée aux utilisateurs pour toutes les applications préinstallées qui utilisent l'autorisation
INSTALL_PACKAGES. - Assurez-vous que le développeur est tenu contractuellement 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 des applications d'installation avec l'API Google Safe Browsing avant de diffuser des applications sur l'appareil.
Signature d'application
Les signatures d'application 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. 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 commune à plusieurs appareils.
- Assurez-vous que les applications ne sont pas signées avec une clé connue publiquement, telle que la clé de développeur AOSP.
- Assurez-vous que les clés utilisées pour signer des 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 permet à une application d'accéder aux autorisations de signature de la plate-forme, qui sont très puissantes et ne sont destinées qu'à ê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 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 à l'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 Android offre une sécurité supplémentaire autour des applications et des processus lorsqu'il est utilisé correctement.
Isolez les processus racine.
Les processus racine sont la cible la plus fréquente des attaques d'escalade de privilèges. Réduire le nombre de processus racine réduit le risque d'escalade de privilèges.
- Assurez-vous que les appareils exécutent le code minimal nécessaire en tant que root. 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 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 disposant de privilèges faibles ou nuls 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, un téléphone), elle ne doit pas exporter de services, de broadcast receivers ni de fournisseurs de contenu accessibles 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 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 approuvées et ne doit exposer l'IPC qu'à d'autres processus approuvés.
- 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 d'application Android offre aux applications une attente d'isolation par rapport aux autres processus du système, y compris les processus racine et les débogueurs. Sauf si le débogage est 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 des dossiers de données d'application individuels, sauf si vous utilisez 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 si vous utilisez 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.