CVE-2015-5256: Apache Cordova vulnerable to improper application of whitelist restrictions on Android

[UPDATE Feb. 24, 2016]
Cordova has updated their announcement regarding CVE-2015-5256. Follow the link for more information: http://cordova.apache.org/announcements/2015/11/20/security.html.

This blog post acknowledges that IBM is aware that Cordova announced two CVEs for vulnerabilities on the Android platform in November 2015. This post will focus on CVE-2015-5256.

The other CVE post can be found here: Weak Randomization of BridgeSecret for Apache Cordova Android

Corodva Announcement

https://cordova.apache.org/announcements/2015/11/20/security.html

CVE-2015-5256: Apache Cordova vulnerable to improper application of whitelist restrictions on Android

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected: Cordova Android 3.7.2 and earlier

Description: Android applications created using Apache Cordova that use a remote server contain a vulnerability where whitelist restrictions are not properly applied. Improperly crafted URIs could be used to circumvent the whitelist, allowing for the execution of non-whitelisted JavaScript.

Upgrade path: Developers who are concerned about this should rebuild their applications with Cordova Android 4.1.1. Developers using remote content roots should also use SSL, as well as Content Source Policy to further mitigate this issue.

Credit: Muneaki Nishimura of Sony Digital Network Applications, Inc</em>

Steps to Mitigation

There is no iFix for this vulnerability. Cordova and IBM can only provide steps to mitigate the issue, primarily encouraging the use of Content Security Policy if available as a stricter whitelist enforcement. Being stricter with your whitelist is the best way to block unwanted redirection.

The following are some suggested steps to mitigate the issue. These steps are to be used in addition to using the existing whitelist.

1. Use Content Security Policy “Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.” It is another layer of added security to help prevent attacks and only allow navigation to URLs that are trusted and specified. It has other nifty protection restrictions that can be set by changing the CSP directives.

   CSP is supported starting with Android 4.4 (KitKat) and all current iOS versions. Adding CSP on older Android versions will have no effect. Follow the remaining mitigation steps to help those on older Android versions.

   CSP should be added to all pages to prevent attacks. If using an iframe, CSP should also be added to the page of the iframe too. To add CSP, use the Content Security Policy <meta> tag in the head of your html file.

   ex. Cordova’s default policy: <meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">

   Cordova has more examples of using CSP directives here: https://github.com/apache/cordova-plugin-whitelist#content-security-policy

   Some more resources of the different directives that can be set:

   • http://content-security-policy.com/

   • https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives#Supported_policy_directives

2. Be specific with your whitelist instead of using wildcards such as ‘*‘
   ex. <access origin="http://some-domain/*" />

   The catch all wildcard is usually useful because you allow all URI under your trusted domain to be loaded, expecting them all to be trustworthy. However, just because the domain is trusted, does not mean that all sources under it are. In the event that the URI under your domain loads a resource from a source that is improperly crafted, it may redirect to an untrusted resource still having the same trusted domain.

   ex. <img src="http://some-domain/http.php?u=http://untrusted.site.some-domain/notMyImage.jpg" />

   In this example, the source of the image redirects to a source that is not whitelisted, but because it begins with the same domain, it gets past the whitelist and loads the image on your page anyway. This is a prime example of how whitelist is not very smart in detecting this redirection.

   Using CSP can prevent the image from loading. CSP has a stricter set of rules and guidelines so will not load sources that you did not allow. If CSP is not available for your users because they are using an older Android version, you can try this instead:

   Instead of using the wildcard “*” in , make an access tag for each of your pages and resources loading from the exact location, not redirected. This may be tedious and cluttering for your config.xml listing out all of your pages, but being explicit will allow the whitelist to do its job properly. Whitelist is not very smart. It is literal and will allow ambiguity if you have ambiguity. This approach will allow you to control specifically what pages and resources are loaded. Redirection is not allowed, only load resources from the exact source.

3. Add checks on the server side if doing redirection using query strings
   If redirection is unavoidable and you can’t do the above two steps because CSP is not available and you have too many pages and resources to list out in your config.xml, then adding secure checks yourself is the next best step. On the server side, check the redirection query string before redirecting. You can keep your own “whitelist” to check against to make sure you are only redirecting to locations that you know are trusted.

4. Use SSL and check SSL URLs
   SSL is a good security measure to use for redirection because it creates a secure link between server and client. When loading from a remote URL, make sure to access trusted URLs using SSL, and that the URLs are really trusted to avoid a redirection to untrusted URLs. </li>

5. Load JavaScript and other resources locally from the application, not a remote URL
   This may not be feasible for all applications since applications can get very big, but it is an option and tradeoff for security. It does ensure that you are only loading trusted sources and don’t need to access anything outside of your own application.

6. Use InAppBrowser
   Lastly, if you need to load a remote URL that you don’t trust, you should consider using InAppBrowser. InAppBrowser behaves like a standard web browser, but without being part of the same Cordova Webview. InAppBrowser brings up another window that is like another web browser, and there you can execute untrusted JavaScript or navigate to untrusted URLs without it affecting your original application. InAppBrowser is not affected by the whitelist and was made for the very reason to load untrusted content.

   InAppBrowser is available as a Cordova plugin and more information can be found here: https://github.com/apache/cordova-plugin-inappbrowser

This security vulnerability is something that can be mitigated by taking several steps to strengthen the security measures of your application. The whitelist will be as secure as you make it. It is not smart enough to always detect redirection or improperly crafted URLs and will allow exactly what you tell it to allow. To avoid risks of redirecting to an untrusted URL, be more specific with your whitelist in addition to adding CSP to all of your pages. CSP is not available on older versions of Android, so further steps are needed to minimize this security risk for those users. Add checks on the server side before redirection and use SSL. The added security measure will help make sure you are redirecting to the proper URL. Loading your sources locally from your application instead of from a remote URL will also make sure that you are not redirected improperly. Lastly, if you intend to load an untrusted source, then try using InAppBrowser. It is a Cordova plugin that opens a separate window apart from your application where all trusted or untrusted activity done in the InAppBrowser won’t affect the original application.

Using only CSP and SSL as Cordova suggested will only apply to a subset of users, so we recommend trying more of the mitigation steps to make sure your application is secure as possible.