[
https://issues.apache.org/jira/browse/CB-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178370#comment-14178370
]
Chris Emerson edited comment on CB-7291 at 10/21/14 1:05 PM:
-------------------------------------------------------------
Thanks for the reply Marcel. So glad to hear 3.6.0 is out even though I can't
see it on the PhoneGap website - I will npm info soon and try that out. Thank
you!
PS: I'm in the RDU area too - small world!
was (Author: chrisemersonnc):
Thanks for the reply Marcel. I'm using PhoneGap, not Cordova, in this case so I
can't just update (AFAIK?) since PhoneGap doesn't yet have a fix for this in a
public build - https://twitter.com/emerson_chris/status/521726447858507776
I'd really prefer to not have to move from PhoneGap to Cordova - but at the
moment sounds like the only way I'll get my app past this security issue Google
is complaining about?
PS: I'm in the RDU area too - small world!
> Externally-launchable applications should be configurable
> ---------------------------------------------------------
>
> Key: CB-7291
> URL: https://issues.apache.org/jira/browse/CB-7291
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
> Affects Versions: 3.5.0
> Reporter: Ian Clelland
> Assignee: Ian Clelland
> Priority: Blocker
> Fix For: 3.6.0
>
>
> Cordova Android versions up to 3.5.0 would launch any and all external
> applications by URL. Any URL not explicitly whitelisted was sent to the
> Android intent system for handling. This was the cause of the security
> vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
> Cordova Android 3.5.1 was released to fix this, which it did by disabling
> explicit intents, and explaining how to use a plugin to block other URL
> schemes if desired.
> We want to have a better official solution than this, so that developers can
> easily configure which applications (sms, email, maps, etc) should be
> launchable from their Cordova app.
> *Proposal*
> The proposed solution is to maintain a second whitelist within the app, for
> URL patterns which may be used to launch external applications. Then, on URL
> loading, these tests will occur (in order):
> # URLs which are whitelisted internally (existing list) will cause internal
> navigation
> # URLs which are whitelisted externally (new list) will attempt to launch an
> intent to handle it
> # URLs which are not whitelisted at all (in neither list) will be blocked.
> *Configuration*
> URLs can be added to the new (external) whitelist through an extension to the
> {{config.xml}} whitelist syntax:
> {code}
> <access origin="sms:*" launch-external="yes" />
> {code}
> (Any non-empty value for the {{launch-external}} attribute will be considered
> "true" when parsing the {{config.xml}} file)
> *Open questions* (one about forward-thinking security, the other about
> backwards-compatibility):
> # What should the default external whitelist be in the application template
> that we ship? This will be the case for new apps build with 3.6.0.
> # What should the default external whitelist be when there are no {{<access
> launch-external="yes">}} tags in {{config.xml}}? This will be the case for
> apps which are upgrading to 3.6.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
