Fixing a Cross App Scripting Vulnerability

This information is intended for developers with app(s) that contain Cross-App Scripting vulnerability.

What’s happening

One or more of your apps contain a WebView Cross-App Scripting issue which can allow malicious apps to steal user cookies and other data. Vulnerable locations in your app can be found in the Play Console notification for your app. If a location ends with “(in dynamically loaded code)” then the location is in code dynamically loaded by the app or by libraries used by the app. Applications typically use dynamically loaded code through on-demand feature delivery, though other unrecommended techniques exist (some unrecommended techniques also violate the Google Play policy and should not be used). Additionally, packers can transform application code into dynamically loaded code.

After the deadlines shown in your Play Console, any apps that contain unfixed security vulnerabilities may be removed from Google Play.

Action required​

1. Sign in to your Play Console, and navigate to the Alerts section to see which apps are affected and the deadlines to resolve these issues.
2. Update your affected apps and fix the vulnerability.
3. Submit the updated versions of your affected apps.

During this time your new app or app update will be in a pending publication status until your request is reviewed. If the app has not been updated correctly, you will still see the warning.

Additional details

WebViews that enable JavaScript and load data read from untrusted Intents can be tricked by malicious apps into executing JavaScript code in an unsafe context. We recommend that you prevent this vulnerability in one of the following ways:

Option 1: Ensure that affected activities are not exported

Find any Activities with affected WebViews. If these Activities do not need to take Intents from other apps you can set android:exported=false for the Activities in your Manifest. This ensures that malicious apps cannot send harmful inputs to any WebViews in these Activities.

Option 2: Protect WebViews in exported activities

If you want to set an Activity with an affected WebView as exported then we recommend that you make the following changes:

1. Protect calls to evaluateJavascript and loadUrl

   Ensure that parameters to evaluateJavascript are always trusted. Calling evaluateJavascript using unsanitized input from untrusted Intents lets attackers execute harmful scripts in the affected WebView. Similarly, calling loadUrl with unsanitized input containing javascript: scheme URLs lets attackers execute harmful scripts.

2. Prevent unsafe file loads

   Ensure that affected WebViews cannot load the cookie database. WebViews that load unsanitized file:// URLs from untrusted Intents can be attacked by malicious apps in two steps. First step: a malicious web page can write <script> tags into the cookies database. Second step: this modified cookies database file can be loaded if a malicious app sends an Intent with a file:// URL pointing to your WebView cookies database, or if the malicious webpage itself redirects your WebView to the file URL. The malicious <script> stored in the cookies database will load and execute, which can steal session information.

   You can ensure that affected WebViews cannot load the WebView cookies database in three ways.

   1. Disable all file access.
   2. Make sure that the WebView only loads file:// URLs and verify that any loaded file:// URLs point to safe files. Note that an attacker can use a symbolic link to trick checks on the URL path. To prevent such an attack, be sure to check the canonical path of any untrusted file:// URL before loading instead of just checking the URL path.
   3. If you want to allow both http:// URLs and file:// URLs, implement the file:// URL verification using shouldOverrideUrlLoading and shouldInterceptRequest in WebViewClient. This ensures that all URLs loaded into WebView are verified, not limited to the URLs directly provided to a loadUrl() function call.

We’re here to help
If you have technical questions about the vulnerability, you can post to Stack Overflow and use the tag “android-security.” For clarification on steps you need to take to resolve this issue, you can contact our developer support team.