Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Meilleures pratiques de sécurité des applications

Cette section contient des recommandations pour garantir 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 la révision manuelle et automatisée du code source.

  • Suivez les consignes de sécurité complètes lors des examens pour assurer la couverture. Utiliser des normes internes ou externes pertinentes pour assurer des examens cohérents et complets.
  • Exécutez un linter, tel que le linter Android Studio , sur tout le code d'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 mémoire tampon et les erreurs ponctuelles.
  • Le système de construction 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é avec le fuzzing, pris en charge dans Android via libFuzzer , les désinfectants peuvent découvrir des cas marginaux inhabituels nécessitant une enquête plus approfondie.
  • Un évaluateur de sécurité compétent doit examiner le code à risque plus élevé, tel que la cryptographie, le traitement des paiements et le traitement des informations personnelles.

Test automatisé

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 rapidement les problèmes et réduire le temps de correction. Android utilise CTS dans le cadre d'une intégration continue dans notre processus de construction automatisé, qui se construit plusieurs fois par jour.
  • Automatisez les tests de sécurité des interfaces, y compris les tests avec des entrées malformées (test fuzz). Le système de construction d'Android prend en charge libFuzzer pour l'écriture de tests fuzz.

Analyse de vulnérabilité

L'analyse des vulnérabilités peut aider à 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 nuisibles (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 sur la manière dont Google les combat dans le Play Store, consultez la documentation destinée aux développeurs 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 aux autorisations ou privilèges inutiles. Les autorisations des applications sont décrites dans le fichier AndroidManifest.xml .

  • N'accordez pas d'autorisations ou de privilèges inutiles aux applications préinstallées. Examinez attentivement les applications avec des 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 pour la fonctionnalité de cette application spécifique.
  • Assurez-vous qu'il existe une divulgation utilisateur pour toutes les applications préinstallées qui utilisent l'autorisation INSTALL_PACKAGES .
  • Assurez-vous que le développeur est contractuellement obligé de ne pas installer d'applications en tant qu'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 obligé 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 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 des 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 commune sur 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 les applications sont gérées d'une manière cohérente avec les pratiques standard de l'industrie pour la gestion des clés sensibles, y compris un module de sécurité matérielle (HSM) qui fournit un accès limité et contrôlable.
  • 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 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, en particulier lors de l'utilisation de 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 sandboxing Android offre une sécurité supplémentaire autour des applications et des processus lorsqu'il est utilisé correctement.

Isoler les processus racinaires

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 l'autorisation de signature à une application avec des privilèges faibles ou inexistants pour gérer le trafic réseau.
  • Les processus racine ne doivent pas écouter sur une socket réseau.
  • Les processus racine ne doivent pas inclure de runtime à usage général, comme une machine virtuelle Java).

Isoler les applications système

En général, les applications préinstallées ne doivent pas fonctionner avec l'identifiant unique (UID) du système partagé. S'il est nécessaire pour une application d'utiliser l'UID partagé du système ou d'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 approuvés.
  • Les processus système ne doivent pas écouter sur une socket réseau. Il s'agit d'une exigence CTS.

Isoler les processus

Le bac à sable d'application Android fournit aux applications une attente d'isolation par rapport aux 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 dans les 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, à moins d'utiliser 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.