Corriger une faille de script multi-application

Ces informations sont destinées aux développeurs d'applications contenant une faille de script multi-application (Cross-App Scripting).

Que se passe-t-il ?

Une ou plusieurs de vos applications présentent un problème de script multi-application WebView qui peut permettre à des applications malveillantes de voler des cookies utilisateur et d'autres données. Veuillez consulter la notification dans la Play Console. Passé les délais indiqués dans la Play Console, toutes les applications présentant des failles de sécurité non résolues pourront être supprimées de Google Play.

Action requise​

1. Connectez-vous à la Play Console et accédez à la section "Alertes" pour savoir quelles sont les applications concernées et connaître les délais à respecter pour résoudre ces problèmes.
2. Mettez à jour les applications concernées et corrigez la faille.
3. Envoyez les versions mises à jour des applications concernées.

Pendant ce temps, votre nouvelle application ou mise à jour d'application sera associée à l'état En attente de publication. Si l'application n'a pas été mise à jour correctement, le message d'avertissement reste affiché.

Informations supplémentaires

Les classes WebView qui activent JavaScript et chargent les données lues à partir d'Intents non fiables peuvent être trompées par des applications malveillantes lors de l'exécution de code JavaScript dans un contexte non sécurisé. Nous vous recommandons de corriger cette faille en appliquant l'une des méthodes suivantes :

Option 1 : S'assurer que les activités affectées ne sont pas exportées

Recherchez des classes Activity comportant des classes WebView posant problème. Si ces classes Activity n'ont pas besoin de prendre des Intents d'autres applications, vous pouvez définir android:exported="false" pour les classes Activity dans votre fichier Manifest. De cette manière, les applications malveillantes ne peuvent pas envoyer d'entrées dangereuses à des classes WebView dans ces classes "Activity".

Option 2 : Protéger les classes WebView dans les activités exportées

Si vous voulez définir comme élément exporté une classe Activity avec une classe WebView posant problème, nous vous recommandons d'apporter les modifications suivantes :

1. Protégez les appels vers evaluateJavascript et loadUrl

   Assurez-vous que les paramètres associés à evaluateJavascript sont toujours fiables. Appeler evaluateJavascript en utilisant une entrée non rectifiée à partir d'Intents non fiables permet aux pirates informatiques d'exécuter des scripts malveillants dans la classe WebView affectée. De même, appeler loadUrl avec une entrée non rectifiée contenant des URL de schémas javascript: permet aux pirates informatiques d'exécuter des scripts malveillants.

2. Empêchez les chargements de fichiers non sécurisés

   Assurez-vous que les classes WebView affectées ne peuvent pas charger la base de données de cookies. Les classes WebView qui chargent des URL non rectifiées commençant par file:// et obtenues à partir d'Intents non fiables peuvent être piratées par des applications malveillantes en deux étapes. Première étape : une page Web malveillante peut écrire des balises <script> dans la base de données de cookies. Deuxième étape : ce fichier modifié de base de données de cookies peut être chargé si une application malveillante envoie un Intent avec une URL file:// pointant vers votre base de données de cookies WebView, ou si la page Web malveillante redirige elle-même votre WebView vers l'URL de fichier. Le <script> malveillant stocké dans la base de données de cookies est alors chargé et exécuté, et peut voler des informations sur la session.

   Pour vous assurer que les classes WebView affectées ne peuvent pas charger la base de données de cookies WebView, vous avez trois possibilités.

   1. Désactivez tous les accès aux fichiers.
   2. Assurez-vous que la WebView ne charge que les URL file://, et vérifiez que toutes les URL file:// chargées pointent vers des fichiers sécurisés. Sachez qu'un pirate informatique peut tromper les contrôles effectués sur le chemin des URL en utilisant un lien de type symbolic link. Pour éviter ce type d'attaque, vérifiez bien le chemin canonique des URL file:// non fiables avant le chargement au lieu de simplement contrôler le chemin des URL.
   3. Pour autoriser les URL http:// et file://, mettez en place la validation des URL file:// URL à l'aide des méthodes shouldOverrideUrlLoading et shouldInterceptRequest dans la classe WebViewClient. Ainsi, toutes les URL chargées dans WebView sont validées, pas seulement celles directement transmises à un appel de fonction loadUrl().

Nous sommes là pour vous aider
Si vous avez des questions techniques sur cette faille, vous pouvez publier un message sur le site Stack Overflow en utilisant le tag "android-security". Si vous souhaitez obtenir des éclaircissements sur les étapes à suivre pour résoudre ce problème, vous pouvez contacter notre équipe d'assistance pour les développeurs.