Bonnes pratiques concernant la sécurité des applications

Cette section contient des recommandations pour assurer la sécurité des applications sur les appareils Android.

Revue de code

L'examen du code source permet de détecter un large éventail de problèmes de sécurité, y compris ceux identifiés dans ce document. Android recommande vivement d'effectuer une revue de code manuelle et automatisée.

  • Suivez des consignes de sécurité complètes lors de vos examens pour vous assurer de 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 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 de décalage d'une unité.
  • Le système de compilation Android est compatible avec de nombreux outils de nettoyage LLVM, tels qu' AddressSanitizer et UndefinedBehaviorSanitizer, qui peuvent être utilisés pour l'analyse au moment 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 nettoyage 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 plus élevé, tel que le chiffrement, le traitement des paiements et le traitement des informations personnelles.

Tests automatiques

Les tests automatiques 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 rapidement et réduire le délai de correction. Android utilise CTS dans le cadre de l'intégration continue de notre processus de compilation automatisé, qui s'exécute plusieurs fois par jour.
  • Automatisez les tests de sécurité des interfaces, y compris les tests avec des entrées mal formées inputs (fuzz testing). Le système de compilation Android est compatible avec libFuzzer pour l'écriture de tests de fuzzing.

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 résoudre 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 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. 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 applications potentiellement dangereuses et sur la façon dont Google les combat dans 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 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 des privilèges inutiles. Les autorisations des applications sont décrites dans le fichier AndroidManifest.xml.

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 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 commune à plusieurs appareils.

  • Assurez-vous que les applications ne sont pas signées avec une clé connue du public, telle que la clé de développeur AOSP.
  • Assurez-vous que les clés utilisées pour signer des applications sont gérées d'une manière conforme 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 la 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 à ê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 lors de la création d'une application pour différents appareils, en particulier lorsque vous utilisez la clé de la 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 Android offre une sécurité supplémentaire pour les applications et les 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 réduit 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 racine 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 inter-processus (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 d'environnement d'exécution à usage général, tel qu'une Java VM.

Isoler les applications système

En règle générale, 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 offre aux applications une 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 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 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.