Cette page propose des contenus d'aide pour les fournisseurs de SDK utilisant la Google Play SDK Console.
Si vous êtes un développeur d'applications et si vous recherchez du contenu d'aide concernant la Google Play Console, utilisez la barre de recherche ou revenez à la page d'accueil.
Vous pouvez utiliser la SDK Console pour rester informé des potentiels problèmes concernant les règles ou des failles de sécurité qui affectent les versions de votre SDK. Il est important de rester à l'affût de ces types de problèmes pour que Google Play reste un environnement sécurisé et pour éviter d'éventuelles conséquences négatives pour vos SDK. Cela peut inclure la suppression de leur badge d'enregistrement ou la restriction de l'accès aux fonctionnalités de la Google Play SDK Console.
Versions du SDK avec de potentiels problèmes concernant les règles
Si vous disposez de versions de SDK connues pour entraîner le non-respect de nos Exigences concernant les SDK ou d'autres Règles du programme Google Play pour les développeurs par les applications qui les utilisent, ces versions seront libellées comme telles dans la SDK Console. Les nouvelles versions d'applications publiées sur Google Play qui utilisent ces versions du SDK seront refusées. Les développeurs seront également invités à trouver une version conforme avant d'envoyer de nouveau leur application.
La capture d'écran ci-dessous montre un exemple de version de SDK avec un cas de non-respect des règles mis en évidence :
La capture d'écran ci-dessous montre un exemple de version du SDK développée, qui détaille le problème signalé :
Conformément aux conditions d'utilisation de la SDK Console, si nous constatons un problème concernant les règles dans votre SDK, vous recevrez une notification et des instructions pour le résoudre et envoyer une nouvelle version du SDK pour examen. Une fois la mesure d'application du règlement terminée pour les applications existantes, la SDK Console indiquera que les versions problématiques du SDK ne respectent pas les règles. Les nouvelles versions d'applications qui les utilisent ne pourront pas être publiées tant qu'elles ne les auront pas remplacées par une version conforme.
Conséquences potentielles en cas de non-respect répété des règles liées au SDK
Google Play s'engage à favoriser un écosystème sûr et fiable pour les développeurs et les utilisateurs. Pour tenir cet engagement, nous mettons en place une approche améliorée afin de limiter les cas répétés de non-respect des règles de Google Play causés par des SDK :
En fonction de la gravité et de la fréquence des cas de non-respect, les conséquences peuvent inclure, mais sans s'y limiter :
- La suppression du badge d'enregistrement : les cas de non-respect répétés et/ou la gravité du non-respect peuvent entraîner la suppression du badge d'enregistrement affiché dans le Google Play SDK Index. Le badge indique que le SDK est enregistré dans la Google Play SDK Console et que le fournisseur de ce SDK a accepté les conditions d'utilisation de la Google Play SDK Console, et s'est donc engagé à ce que les applications basées sur ses SDK n'enfreignent pas les règles Google Play.
- La limitation de l'accès aux fonctionnalités de la Google Play SDK Console : si des SDK entraînent des cas répétés de non-respect du règlement par des développeurs d'applications ou selon la gravité du non-respect, nous nous réservons le droit de supprimer l'accès aux principales fonctionnalités de la SDK Console.
Remarque : Les fournisseurs de SDK peuvent toujours demander des informations sur une décision. Pour en savoir plus, consultez cet article du Centre d'aide sur l'utilisation sécurisée des SDK et le Règlement du programme pour les développeurs de Google Play.
Versions du SDK avec de potentielles failles de sécurité
Une faille désigne une vulnérabilité ou un défaut dans le code, qu'une personne malveillante pourrait exploiter. La SDK Console vous informe des potentielles failles de sécurité qui affectent les versions de vos SDK. Vous trouverez ci-dessous des informations sur les failles susceptibles d'affecter votre SDK et la façon de les corriger.
Corriger les SDK qui contiennent des formats de chiffrement non sécurisés
Votre SDK contient des formats de chiffrement non sécurisés. En d'autres termes, un texte chiffré est généré avec une clé secrète, un salage ou un vecteur d'initialisation (IV) à calcul statique.
Si une application utilise votre SDK, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez les emplacements du code de chiffrement non sécurisé dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Examinez votre SDK à la recherche de clés, de vecteurs d'initialisation et/ou de salages à calcul statique utilisés dans les opérations de chiffrement, et assurez-vous que ces valeurs sont conçues de manière sécurisée. Par exemple, le code suivant utilise une clé secrète à calcul statique et un vecteur d'initialisation calculable de manière statique :
// L'alerte dans la Console fait référence à cette méthode
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
Cipher cipher = Cipher.getInstance(“AES/GCM/NoPadding”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
GCMParameterSpec paramSpec = new GCMParameterSpec(256, iv.getBytes());
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
// La clé non sécurisée et le vecteur d'initialisation sont ici et doivent être modifiés
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
Valeurs calculées de manière statique
Une valeur calculée de manière statique est une valeur identique à chaque exécution d'une fonction. Les valeurs calculées de manière statique peuvent être extraites de votre SDK et utilisées pour attaquer les données chiffrées d'une application. Même si vous manipulez les clés, les vecteurs d'initialisation et les salages de manière complexe avant leur utilisation, ils restent peu fiables si ces manipulations sont identiques pour chaque exécution du programme.
Bonnes pratiques Android
Nous vous recommandons d'utiliser Jetpack Security pour la cryptographie symétrique. Si votre SDK chiffre des clés API, des informations permettant d'identifier personnellement l'utilisateur ou d'autres données sensibles, EncryptedSharedPreferences peut être utilisée pour stocker ces données en toute sécurité, sans se soucier de l'implémentation de clés secrètes, de vecteurs d'initialisation ni de salages. D'autres bonnes pratiques et exemples sont disponibles sur cette page. Pour transmettre des données vers d'autres systèmes de façon sécurisée, les développeurs doivent utiliser le protocole TLS/SSL pour sécuriser les données en cours de transmission.
Jetpack Security utilise Tink, le projet Open Source de Google, pour gérer le chiffrement à authentification symétrique. Pour les cas d'utilisation avancée concernant les opérations de niveau inférieur, nous vous conseillons d'utiliser directement Tink.
Si les bonnes pratiques Android mentionnées ci-dessus ne correspondent pas à votre utilisation et que vous devez gérer explicitement les clés, vecteurs d'initialisation et salages, nous vous recommandons de respecter les normes suivantes :
- Clés secrètes : les clés secrètes symétriques doivent être imprévisibles et secrètes. Pour le chiffrement des données locales, les développeurs doivent concevoir des clés secrètes à l'aide de valeurs aléatoires sécurisées (ou à partir de données générées par l'utilisateur si PBEKeySpecs est utilisé), et stocker les clés secrètes via AndroidKeystore.
- Vecteurs d'initialisation : les vecteurs d'initialisation doivent être uniques et imprévisibles pour plusieurs messages, mais ils n'ont pas besoin d'être secrets. Les développeurs doivent concevoir des vecteurs d'initialisation en utilisant des éléments aléatoires sécurisés cryptographiquement. Les développeurs doivent stocker ou transmettre les vecteurs d'initialisation avec le texte chiffré associé.
- Salages : les salages doivent être uniques et imprévisibles sur plusieurs hachages, mais ils n'ont pas besoin d'être secrets. Les développeurs doivent construire des salages à l'aide d'éléments aléatoires sécurisés cryptographiquement. Les développeurs doivent stocker ou transmettre les salages avec les hachages associés.
Corriger les SDK qui utilisent des formats de chiffrement moins sécurisés
Votre SDK contient un chiffrement basé sur le mode AES/ECB, qui est moins sécurisé. Chiffrer du contenu avec ce mode peut affaiblir l'efficacité du texte chiffré et exposer les données utilisateur à des risques.
Si une application utilise votre SDK, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez les emplacements du code des formats de chiffrement moins sécurisés dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Vérifiez l'emplacement où un algorithme de chiffrement est instancié dans votre SDK. Les modes de configuration suivants impliquent l'utilisation du mode AES/ECB non sécurisé :
"AES"
"AES/ECB/NoPadding"
"AES/ECB/PKCS5Padding"
"AES/ECB/ISO10126Padding"
Par exemple, le mode AES/ECB est utilisé par défaut dans le code ci-dessous, car la valeur "AES" a été fournie :
// L'alerte dans la Console fait référence à cette méthode
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// Utilise le mode AES/ECB par défaut
Cipher cipher = Cipher.getInstance(“AES”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
renvoie cipher.doFinal(plainText);
}
Google recommande aux développeurs d'utiliser "AES/GCM/NoPadding" au lieu du mode non sécurisé mentionné précédemment.
Corriger les SDK contenant du code vulnérable à la traversée de répertoire ZIP
Le code de votre SDK contient des formats de décompression non sécurisés qui peuvent entraîner une attaque par traversée de répertoire ZIP.
Si une application utilise votre SDK, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure détaillée ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez les emplacements des formats de compression non sécurisés dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Les fichiers ZIP peuvent contenir une entrée (fichier ou répertoire) dont le nom contient des caractères de traversée de répertoire ("../"). Si les développeurs décompressent ces entrées sans valider leur nom, cela peut entraîner une attaque par traversée de répertoire conduisant à des modifications de répertoire arbitraires, voire à l'écrasement de fichiers dans les dossiers privés d'une application.
Pour corriger cette faille dans votre SDK, nous vous recommandons de vérifier si les chemins d'accès canoniques aux fichiers décompressés se trouvent sous le répertoire attendu. Plus précisément, avant d'utiliser un objet File créé à l'aide de la valeur renvoyée par la méthode getName() de ZipEntry, vérifiez toujours que la valeur renvoyée par File.GetCanonicalPath() appartient au chemin d'accès du répertoire souhaité. Exemple :
InputStream is = new InputStream(untrustedFileName);// SecurityException
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
while((ZipEntry ze = zis.getNextEntry()) != null) {
File f = new File(DIR, ze.getName());
String canonicalPath = f.getCanonicalPath();
if (!canonicalPath.startsWith(DIR)) {
}// Terminer la décompression...
}
Corriger les SDK qui contiennent un PendingIntent implicite
Votre SDK contient un PendingIntent implicite, ce qui peut entraîner des problèmes de sécurité comme un déni de service, un vol de données privées et une élévation des privilèges.
Si une application utilise votre SDK, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure détaillée ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez les emplacements du code du PendingIntent implicite dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Les applications Android utilisent les intents pour envoyer des messages entre différents composants. Les intents peuvent soit préciser le composant cible (intent explicite), soit indiquer une action générale. Dans ce cas, le système d'exploitation confie l'intent à n'importe quel composant de l'appareil dont le filtre d'intent correspond à cette action (intent implicite).
Un PendingIntent est un intent délégué à une autre application et qui sera traité ultérieurement. Créer un intent implicite encapsulé dans un PendingIntent représente une faille de sécurité qui peut provoquer un déni de service, un vol de données privées et une élévation des privilèges.
Vérifiez si votre SDK contient un PendingIntent. Par exemple, le code suivant crée un PendingIntent encapsulant un intent implicite :
// Créer un intent de base implicite et l'encapsuler dans un PendingIntent
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google recommande aux développeurs de corriger la faille en appliquant l'une des mesures suivantes (voire toutes, si possible) :
- Assurez-vous que les champs d'action, de package et de composant de l'intent de base sont définis.
- Assurez-vous que le PendingIntent n'est transféré qu'à des composants approuvés.
- Utilisez FLAG_IMMUTABLE (ajouté dans le SDK 23) pour créer des PendingIntents. Cela empêche les applications qui reçoivent le PendingIntent de compléter des propriétés non renseignées. Si l'application fonctionne également sur des appareils exécutant le SDK 22 ou une version antérieure, nous recommandons aux développeurs d'appliquer les options précédentes tout en renforçant la création de PendingIntents à l'aide du modèle suivant :
if (android.os.Build.VERSION.SDK_INT >= 23) {
// Créer un PendingIntent en utilisant FLAG_IMMUTABLE
} else {
// Code existant qui crée un PendingIntent
}
Corriger les SDK contenant une faille liée à un intent interne implicite
Votre SDK contient un problème d'intent interne implicite. Les intents implicites utilisés pour accéder à un composant interne permettent aux pirates informatiques d'intercepter le message et de le supprimer, de le lire ou même d'en remplacer le contenu.
Si une application utilise votre SDK vulnérable, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure détaillée ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez le ou les emplacement(s) des intents implicites utilisés dans votre SDK dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Vérifiez si votre application contient un intent implicite. Le code suivant utilise par exemple des intents implicites pour accéder à un composant interne :
//L'application contient un composant qui enregistre MY_CUSTOM_ACTION,
//une action enregistrée uniquement par cette application, ce qui indique que le développeur souhaite que cet intent
//soit transmis au composant interne de façon sécurisée.
Intent intent = new Intent("MY_CUSTOM_ACTION");
//Ajoutez du contenu sensible à l'intent
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google recommande aux développeurs d'utiliser des intents explicites pour accéder à leurs composants internes, par exemple :
- Intent.setComponent pour définir explicitement le composant servant à gérer l'intent ;
- Intent.setClass ou Intent.setClassName pour définir explicitement le composant cible ;
- Intent.setPackage pour limiter les composants ciblés par cet intent.
Corriger les SDK contenant des bibliothèques JavaScript vulnérables
Votre SDK contient une ou plusieurs bibliothèques JavaScript présentant des problèmes de sécurité connus (par exemple, des CVE, c'est-à-dire des failles et expositions courantes). L'inclusion de bibliothèques vulnérables dans votre SDK peut mettre en danger les utilisateurs de votre application.
Si une application utilise votre SDK vulnérable, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez le problème dans votre SDK.
Suivez la procédure détaillée ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez une liste des bibliothèques non sécurisées détectées et de leurs versions utilisées dans votre SDK dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Pour résoudre ce type de problème, vous pouvez effectuer l'une des trois actions suivantes pour chaque bibliothèque non fiable détectée :
- Utiliser une version à jour de la bibliothèque : si votre SDK dépend directement d'une version non sécurisée d'une bibliothèque, et que le problème de sécurité est résolu dans la dernière version de cette bibliothèque, vous pouvez compiler de nouveau le SDK avec cette dernière version pour résoudre le problème.
- Contacter le développeur de la bibliothèque : il est possible que la maintenance de la bibliothèque soit toujours assurée, mais que le problème de sécurité n'ait pas encore été résolu. Il est également possible que votre SDK ait une dépendance transitive par rapport à la bibliothèque non sécurisée détectée (par exemple, le SDK dépend directement d'une bibliothèque qui dépend elle-même de la bibliothèque non sécurisée). Dans ce cas, contactez le développeur de la bibliothèque pour résoudre le problème.
- Trouver une alternative : si la maintenance de la bibliothèque non sécurisée (contenant un ou plusieurs problèmes de sécurité) n'est plus assurée, recherchez et utilisez une autre bibliothèque sécurisée.
Corriger les SDK qui utilisent des WebViews pour l'authentification
Votre SDK utilise WebView pour l'authentification, ce qui n'est pas recommandé. L'utilisation de WebViews pour les requêtes OAuth 2.0 nuit à la sécurité et la facilité d'utilisation des applications qui utilisent votre SDK. Suivez la procédure ci-dessous pour résoudre le problème dans votre SDK.
Si une application utilise votre SDK, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Vous pouvez trouver les emplacements du code des requêtes OAuth 2.0 via WebViews dans votre SDK dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Depuis la sortie des onglets personnalisés Chrome, Google recommande aux développeurs de ne plus utiliser les WebViews pour l'authentification. L'utilisation du protocole OAuth pour l'authentification dans un Webview peut nuire à la sécurité et la facilité d'utilisation des applications utilisant votre SDK en déconnectant l'utilisateur des sessions d'authentification unique. Les onglets personnalisés Chrome permettent de limiter ces problèmes.
- Recherchez d'où proviennent les requêtes OAuth 2.0 via WebView dans votre SDK.
- Google recommande aux développeurs de remplacer ce composant WebView par un onglet personnalisé pour Chrome. Pour ajouter un onglet personnalisé à votre application, suivez les étapes décrites dans le guide d'implémentation des onglets personnalisés Chrome.
- Utilisez l'onglet personnalisé Chrome ajouté pour exécuter la requête OAuth 2.0.
Corriger les SDK qui divulguent des clés API GCP
Votre SDK contient une ou plusieurs clés API Google Cloud Platform (GCP) divulguées. Si vous avez intégré des clés API GCP dans vos SDK, sachez que ces clés seront accessibles à tous. L'exposition de vos clés API peut entraîner des frais et des changements de quota inattendus dans le compte GCP de votre SDK.
Si une application utilise votre SDK vulnérable, elle recevra une alerte dans la Play Console. Pour éviter que les applications qui utilisent votre SDK reçoivent des alertes, corrigez la faille dans votre SDK.
Suivez la procédure détaillée ci-dessous pour résoudre le problème dans votre SDK. Vous trouverez les emplacements des clés API GCP divulguées dans votre SDK dans la notification de la SDK Console concernant votre SDK.
Informations supplémentaires
Nous vous recommandons de résoudre le problème dans votre SDK de l'une des manières suivantes :
- Si possible, utilisez des comptes de service GCP au lieu de clés API GCP pour les besoins d'authentification de votre application. Un compte de service GCP est un compte Google associé à votre projet GCP. Pour en savoir plus sur la création et l'utilisation des comptes de service, consultez cette page.
- Ajoutez des restrictions à votre clé API afin que seules vos applications/SDK soient autorisés à l'utiliser. Pour en savoir plus sur l'ajout de restrictions aux clés API, consultez cette page. Remarque : Si vous avez ajouté des restrictions à votre clé API, vous pouvez ignorer cet avertissement.