*Action Required* Cordova-Android Security Update
Security vulnerabilities in the Cordova Android framework were recently discovered by a team of researchers in IBM. When chained together, these vulnerabilities could lead to an exploit where sensitive and private data from any Cordova based hybrid application can be leaked to a remote server. This attack can be triggered just by browsing to a malicious web page that uses an intent:// URL to launch the targeted Cordova application but with a modified start page that belongs to the attacker. This modified malicious start page could use the
These security issues have been documented as:
CVE-2014-3500 - Cordova cross-application scripting via Android intent URLs
CVE-2014-3501 - Cordova whitelist bypass for non-http URLs
CVE-2014-3502 - Cordova apps can potentially leak data to other apps via android intent URLs
You can read the Apache Cordova announcement here: http
A new version of Apache Cordova has been released that addresses security issues that were found in the Android platform. We have backported these security fixes to the following versions of Worklight: 5.0.6, 6.0, 6.1, 6.2. All customers who build hybrid applications for Android should immediately install the iFix and take the following steps to ensure your application and users are secure:
1. Install the new Worklight Studio iFix.
2. Modify the Cordova whitelist to add any non-http/s protocols your application uses, such as mailto:, geo:, sms:, market://, etc.
3. Rebuild your Android application and redeploy to your users
4. Use Worklight Server tools to ensure users upgrade to your new application version. This is not the same as an "in app update" but in fact an upgrade of the actual Android apk installed on the device.
1. Install the new Worklight Studio iFix.
Because these fixes affect native Cordova code that runs on the device, all customers will need to download the appropriate Worklight Studio iFix and rebuild their applications. This will ensure that the internal Cordova Android code inside your applications gets refreshed with the security fixes. Because Cordova runs only on the client device, Worklight Server and other products are not affected. The iFixes are available from Fix Central. The patched code is available for the following streams:
Note that on Worklight versions 6.1 and later, after installing the iFix you will need to remove the Android environment and then add it back to your application. This will put the new cordova.jar file into your project from Worklight Studio. If you have made any manual Android environment customizations, save them before removing the Android environment so that you can restore them after adding the Android environment back to your application.
The quickest way to verify that the patch was correctly applied is to:
1. Find and copy the cordova.jar file to a temporary directory. The cordova.jar file is located in yourProject --> Apps --> yourProject --> android --> native --> libs --> cordova.jar
2. Navigate to the temporary folder where you placed the copy of cordova.jar and unzip the jar file. You can do this by opening a command prompt and typing "unzip cordova.jar"
3. Search for org/
3. Modify the Cordova whitelist
One of the security fixes involves creating a new whitelist for non http/s protocols. If your application uses other protocols besides http:// and https://, such as sms:, mailto:, geo:, etc., then you will need to make some configuration changes to add these protocols to the whitelist. This is easy to do:
1. Open up the Cordova config.xml file, located at: yourProject --> apps --> yourProject --> android --> native --> res --> xml --> config.xml. Note: If you have a file located at yourProject --> apps --> yourProject --> android --> nativeResources --> res --> xml, you will have to make the changes to this file (under the nativeResources folder) instead, since if this file exists, it will overwrite the config.xml in /native/ folder when the app is rebuilt.
2. Scroll to your whitelist entries. You should see items listed like this:
<access orig
<access orig
3. For every non http/https protocol that you use, you will have to add a whitelist entry like this:
<access origin="sms://*" laun
<access origin="mailto://*" laun
The launch-external attribute will tell Cordova to allow this URL to be handled by other applications in Android system - not by the currently running Cordova/Worklight application. This will mean that when a user clicks on a <a href="sms:555..."> link, Android will let whatever application is registered to sms: handle the request.
If the only entry that is in your whitelist looks like this:
<access origin="*" />
then your application will allow resource requests to any internet resource, which could open your application to certain kinds of attacks. You should list specific domains in this tag that you want to be able to access.
If your whitelist looks like this:
<access orig
<access orig
and inside your application you utilize the mailto: protocol to open a user's email client, and the geo: protocol to display a map, then you should modify the whitelist to look like:
<access orig
<access orig
<access origin="mailto://*" laun
<access origin="geo://*" laun
If you do not utilize any protocol other than file://, data://, and content://, then you can leave your whitelist as is. (Since file://, data://, and content:// are essential protocols for Cordova internals, these protocols are allowed by default and do not need to be in the whitelist explicitly.) All actions that use protocols that are not added to the whitelist will be treated no-ops and ignored by Cordova.
4. Rebuild your application and redeploy to your users
After making these changes to the whitelist (if needed), you will have to rebuild your Android application. Rebuilding with the iFix installed will ensure that your application's internal Cordova code is patched. Even if you did not need any changes to the whitelist, you still need to install the iFix and rebuild your Android application. After this, you will need to redeploy your application to your users as an update.
5. Use Worklight Server tools to ensure users upgrade
Even if you follow the above steps and create a new Android application, it is critical that your users actually download and install the updated application. Until they do this, users will be vulnerable to attack because of the outdated Cordova code. You can use Worklight server to remotely disable your application and force users to download the update if they want to continue using your service. The following instructions are for Worklight 6.2 and are from the Knowledge Center located at:
Please refer to the appr
Deploying a new app version and blocking the old version
1. Optional - send notification message to users of the old version, announcing a mandatory update in a few days. See Displaying a notification message on application startup and Defining administrator messages from Worklight Console in multiple languages.
2. In Worklight Studio, increment the app version number.
3. Build and test your project and generate new .wlapp and .apk files for it.
4. Deploy the new .wlapp file to Worklight Server.
5. Submit the new .apk file to the Android app stores.
6. Wait for review and approval, and for the apps to become available.
7. Copy links to the new app version.
8. Block the old version of the app in Worklight Console, supplying a message and link to the new version. See Locking an application (htt
Please take some time to review the security sections on IBM Developer Works:
Also note that there is a new Cordova security guide:
http [update] Please note that Google Play Store will flag applications built on insecure versions of Cordova: http If your application has been flagged, then you applied the upgrade, you need to trigger the Play store to rescan your application to remove the warn History: August 26 - Added verification steps January 9 - Added notes about 5.0.3.x and 5.0.5.x streams |
Comments (0)
